| Summary: | g++: Internal error: Terminated (program cc1plus) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Justin Brown <justin> |
| Component: | [OLD] GCC Porting | Assignee: | Please assign to toolchain <gcc-porting> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Full output of emerge gnome, till the error
fluxbox compile output gcc compile output my world favorites file |
||
|
Description
Justin Brown
2004-07-30 20:53:14 UTC
Created attachment 36501 [details]
Full output of emerge gnome, till the error
Same problem, different system specs: P4- 2.4 GHz kernel = 2.6.5-gentoo-r1 gcc = 3.3.4-r1 1GB RAM Same problem. Trying to emerge: fluxbox blackbox w3m Thought this was a memory shortage problem first, as I am pretty low on the stuff. P166 MMX 32 MB RAM g++ 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) After letting go of the -pipe and -fomit-frame-pointer CFLAGS, I got w3m to compile cleanly. Any of these that you really shoudn't use at all? Known reasons for them not to work with g++? using CFLAGS="-O2 -mcpu=i586 -march=i586", it still fails to compile fluxbox(.cc). Seems like it's not a CFLAGS issue? Created attachment 44131 [details]
fluxbox compile output
Created attachment 44132 [details]
gcc compile output
Created attachment 44134 [details]
my world favorites file
This is my world favorites file, to show ebuilds that has compiled cleanly on
the same system.
Same Problem Emerging dev-db/mysql-4.0.22 2.6.9-gentoo-r9 #6 SMP Tue Dec 14 12:26:12 EST 2004 i586 Pentium MMX GenuineIntel GNU/Linux 48Mb Ram, 1Gb Swap Pure Terminal, no X installed [/code] g++: Internal error: Terminated (program cc1plus) Please submit a full bug report. See <URL:http://bugs.gentoo.org/> for instructions. make[4]: *** [sql_yacc.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/var/tmp/portage/mysql-4.0.22/work/mysql-4.0.22/sql' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/mysql-4.0.22/work/mysql-4.0.22/sql' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/mysql-4.0.22/work/mysql-4.0.22/sql' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/mysql-4.0.22/work/mysql-4.0.22' make: *** [all] Error 2 [/code] Well, I fixed it. I added an extra 64Mb of ram and it compiled. Ik het is mij gelukt door MAKEOPTS te veranderen in "-j1". Hierdoor heb ik wel fluxbox kunnen compileren Maybe this problem is actually a kernel bug? In fact, I suspect a relation with #91615. I will explain why I think so. It is true that MAKEOPTS="-j1" or using no optimization (-O0) increases the chance of successful compilation, but it does not always help and is only a solution for some symptoms but not of the problem. Moreover, with 512 MB and sufficiently swap it should be possible to compile kde even with strong optimization, shouldn't it? More precisely, if some minimal memory for the kernel are satisfied, I would expect that further memory issues are only a question of the available swap space (and perhaps of time). However, the problem seems to be independent of the available swap space (I experimented with adding (normal or huge) swapfiles and without swap etc). Moreover, I guess that all reporters of this bug will observe that after compiling sufficiently many projects containing c++ (even if successfull) the system will swap much more than usual and perhaps some random processes are killed - a typical effect when the system is short of memory; after rebooting the phenomenon is gone. Setting restrictive ulimit's does not prevent the system from killing tasks also of other users. So I guess the kernel is the only program which might have the rights to do this (however, I do not know how glibc or libstdc++ are embedded into the system - maybe their "memory management" also runs with root permissions in the background and manages the memory of several tasks? In this case it could be that they are the cause of the problem instead of the kernel). It is strange that the problem occurs not during the compilation of c projects (e.g. compiling kernel/emacs/... works perfectly) but with c++ projects (kde, mozilla, firefox, ...). For those of you who have some ideas and want to try: One of the most reproducible cases is when you compile kmail-3.4.0 - with MAKEOPTS="-j2" and sufficiently high optimization flags like CFLAGS="-O4 -fomit-frame-pointer -funswitch-loops -funroll-all-loops -fpeel-loops -ftracer -pipe" this will almost certainly die during compilation of libkmailprivate_la.all_cpp.cpp (tested with gcc-3.4.3.20050110-r2 on amd64 and x86). I forgot to mention: When you want to test, be sure to rename /usr/bin/ccache first - if the compiler cache has already stored your files, this would prevent of course the problem to occur. *** This bug has been marked as a duplicate of 20600 *** |
