Hans-Peter Jansen wrote:
Am Mittwoch, 12. September 2007 00:26 schrieb Danny Pansters:
I've seen this on FreeBSD when compiling with gcc42 (FreeBSD-STABLE=6 has
gcc34, FreeBSD-CURRENT=7 has gcc42 as their system compiler). I'd get
build cluster failures on CURRENT for py-qt4-gui, as well as py-kde (kde3
that is). The cluster quits building if a single (g++) process takes
longer than 2 hours. For py-qt4-gui with gcc42 even on my fat 3.4 GHz
intel box it would never seem to finish.
Turning off concat proved (so far) to be a good solution. Tested with
gcc42 on STABLE. It doesn't take that much longer (perhaps even faster
compared to, say gcc34 with -j 4 which I was already using for py-kde to
help amd/sparc packages to build).
What happens, as far as I can say, is that the cc1plus process lasts for
a very long time (or forever). As if there's something odd where the
number of make invocations and the number of g++ processes don't match up
or perhaps something overflows causing the compiler to go on and and
"optimizing". And even if that work is for nothing it will use up
resources. There's also a known gcc42 <-> python2.5 incompatibility
problem which may or may not play a role.
Whatever the exact issue is, I think it's safe to assume that building
from concatted source should (for now?) be discouraged under GCC42+.
Boys, ever watched your heap in those pathologic cases?
A while back I decided to try building PyQt4 from an SRPM on Fedora 7
(g++ 4.1.2) on a box with dual cores and 1GB RAM. The build process
decided that it would use -j 2, and after over an hour of compiling (and
my system becoming completely unusable) I looked at the memory usage of
the g++ processes. Turns out EACH (of the 2) processes was using MORE
than .5GB of memory so the system was just sitting there thrashing,
nothing else (nothing else it could do at that point). I killed the
whole build process, removed the -j flags and then the whole thing built
in just a few minutes.
Just felt like sharing,
-Adam Batkin
_______________________________________________
PyQt mailing list [email protected]
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
