[Pan-users] Re: Re: Re: Re: 0.92 amd64

[Duncan]

Thomas Stein posted <address@hidden>, excerpted
below,  on Tue, 18 Apr 2006 11:58:39 +0200:

> On Friday 14 April 2006 16:52, Duncan wrote:
> 
>> Well, when you get back...  I just tried compiling it with gcc-3.4.6, and
>> yes, it /does/ use that memory.
> 
> Hola.
> 
> My ulimit is set to unlimited so this can*t be the problem. I have 2Gig 
> of Ram by the way.
> 
> commander ~ # ulimit -a
> core file size          (blocks, -c) 0
> data seg size           (kbytes, -d) unlimited
> file size               (blocks, -f) unlimited
> pending signals                 (-i) 16375
> max locked memory       (kbytes, -l) 32
> max memory size         (kbytes, -m) unlimited
> open files                      (-n) 1024
> pipe size            (512 bytes, -p) 8
> POSIX message queues     (bytes, -q) 819200
> stack size              (kbytes, -s) 8192
> cpu time               (seconds, -t) unlimited
> max user processes              (-u) 16375
> virtual memory          (kbytes, -v) unlimited
> file locks                      (-x) unlimited

I'm still guessing memory is it, as it stopped here at the same spot,
after using all the memory I was giving it to use.

Some hints I used with kmail when i was having that issue (aside from
ulimit):

Drop out of X to the console to do the compilation.  That means X not
running at all, not X running in a different VC.  X and associated window
managers and etc use lots of memory, so drop out of X and you free that
memory.  (You could save a bit more memory by dropping to single user
mode, init 1, but X is the big user in most cases and will likely do it
Don't run any other merges at the same time (probably not an issue here,
but when KDE updates and I have ~100 packages to compile, I'll run
severall merges in parallel most of the time, using --tree and --ask to
ensure I'm not merging the same thing in two instances).

Set MAKEOPTS=j1.  Same idea -- cut down on the parallel tasks so the big
one has more memory to work with.

It needed all of 1.3 gig here.  You say you have two gig, which should
work if you handle things correctly, but obviously, it was using
everything you had and needed more, so you must have had too many other
things running at the same time, given it wasn't ulimit.

You can /try/ adding -fno-unit-at-a-time to your CFLAGS.  GCC won't
be able to optimize as well in this case as it'll work with parts instead
of the whole compilation unit at once, but according to the gcc manpage,
it /should/ save memory.  -funit-at-a-time is enabled by default with -O2,
thus the suggestion to disable it.

There's a gcc-3.4.6-r1 out with a few bugfixes.  Maybe that is one of
them?  Something tells me this is likely a bug with 3.4.6, as yeah, 4.1
might be more efficient, but 1.3 gig compared to 0.3 gig?  That looks like
a bug to me.

Note that gcc is slotted.  You can therefore unmask 4.1.0 and merge it, if
desired, and use gcc-config/eselect to switch between versions.  I /know/
4.1.0 compiles it just fine -- and in less than a third of a gig of
memory, too!  If you don't wish to use a masked  gcc for general system
compiles, don't.  Keep 4.1.0 around for pan and other stuff you might want
it for, but keep 3.4.6(-r1) merged and eselected by default and it'll be
used.  (Be aware of the usual issues with libstdc++ when you switch gcc
versions, and run fix_libtool_files.sh as needed.  It shouldn't be a
problem as long as the old version isn't unmerged, tho, and slots should
take care of that unless you deliberately unmerge the old slot.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html