using portage 2.0.38 and fresh emerge sync, emerge kde-env, emerge arts. emerge kdelibs ends in: creating libkdecore_la.all_cpp.cpp ... /bin/sh ../libtool --mode=compile --tag=CXX i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../libltdl -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/kde/3/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -mcpu=i686 -O3 -pipe -fno-exceptions -fno-check-new -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_COMPAT -c -o libkdecore_la.all_cpp.lo `test -f libkdecore_la.all_cpp.cpp || echo './'`libkdecore_la.all_cpp.cpp i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../libltdl -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I/usr/qt/3/include -I/usr/X11R6/include -I/usr/kde/3/include -DQT_THREAD_SUPPORT -D_REENTRANT -DNDEBUG -DNO_DEBUG -O2 -mcpu=i686 -O3 -pipe -fno-exceptions -fno-check-new -DQT_NO_TRANSLATION -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_COMPAT -c libkdecore_la.all_cpp.cpp -fPIC -DPIC -o .libs/libkdecore_la.all_cpp.o In file included from libkdecore_la.all_cpp.cpp:23: kcharsets.cpp:420:2: warning: #warning FIXME? i686-pc-linux-gnu-g++: Internal error: Terminated (program cc1plus) Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. {standard input}: Assembler messages: {standard input}:308667: Warning: end of file not at end of a line; newline inserted make[3]: *** [libkdecore_la.all_cpp.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdelibs-3.0.3a/work/kdelibs-3.0.3a/kdecore' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdelibs-3.0.3a/work/kdelibs-3.0.3a/kdecore' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdelibs-3.0.3a/work/kdelibs-3.0.3a' make: *** [all] Error 2 !!! ERROR: The ebuild did not complete successfully. !!! Function kde_src_compile, Line -6648, Exitcode 2 !!! died running emake, kde_src_compile:make full emerge kdelibs stdout and stderr streams captured to file at: http://www.chriscalloway.org/emerge_kdelibs_nodeps_streams kdelibs being emerged was kdelibs-3.0.3a. make.conf showing USE values at: http://www.chriscalloway.org/make.conf hardware is IBM 770E laptop with 160M ram and 320M swap. same problem occurs if emerge kde from scratch. isolated error to emerge kdelibs. gcc is 3.2-r1.
Sounds like you're out of memory or something. kdelibs is a very very heavy compile at that particular point. Try this: edit /usr/portage/eclass/kde-dist.eclass, remove or comment out the line that says 'myconf="$myconf --enable-final"', try emerging kdelibs again. Also don't put -pipe in your CFLAGS.
thanks for responding. i did as you suggested. the result was the same exact error in the same exact place. also, when commenting out the line in /usr/portage/eclass/kde-dist.eclass as suggested, i noticed the file is headed by a comment which reads: "Don't use for kdelibs" i understand under ordinary circumstances i should suspect not enough memory when compiling. but if 160M ram with 320M swap is not enough, then what is? if there is a memory requirement, it would be desirable to state it. furthermore, when the compile error occurs, three things stick out in stderr like a sore thumb: 1) kcharsets.cpp:420:2: warning: #warning FIXME? 2) i686-pc-linux-gnu-g++: Internal error: Terminated (program cc1plus) 3) Please submit a full bug report. i'm not questioning that lack of memory could be a problem, but i would hope in a mature piece of code such as g++, there would be bounds checking and sensible reporting of bad return codes from malloc, rather than "internal error," "FIXME," and "submit a full bug report." should this bug report be cascaded to gnu.org and made dependent? a number of such kdelibs errors have been reported in the gentoo forums. i observe two things about them: 1) memory is suspected at first but the solutions to those that are solved (involving unmerges, work dir deletions, and merges with --nodeps) turn out to be something else. i have tried all these suggestions from the forums to no avail, btw. 2) such problems also seem to involve the inability of emerge to distinguish between kdelibs-3.0.3a and kdelibs-3.0.3-r1. emerge -p kde reports that emerge would install both kdelibs-3.0.3a and kdelibs-3.0.3-r1. my system appears to exhibit the same behavior. this has been reported by others in bugs 8043 and 8166. thank you again for your time and effort thus far.
I'm sorry, what I told you to do was incorrect. kdelibs indeed doesn't use kde-dist.eclass, I forgot about that :-( So we didn't really change anything. Let's try the right fix for the OOM theory: edit the kdelibs ebuild itself and remove --enable-final (not the whole line though) where it appears. Sorry for wasting your compile time.
thank you for your response. removing --enable-final from the kdelibs ebuild worked for kdelibs. so i went on to emerge the rest of kde and got the same error, now in kdenetwork-3.0.3. but the ebuild for kdenetwork contains no --enable-final. stdout and stderr for emerge kde: http://www.chriscalloway.org/emerge_kde_streams
For kdelibs, --enable-final sits in the ebuild. For kdenetwork and the other ebuilds, you have to remove it from kde-dist.eclass as described above. I agree that this shouldn't be like this and I've written to gentoo-core asking to introduce a new USe flag to control --enable-final everywhere it exists.
thank you very much. i commented out --enable-final in kde-dist.eclass again, in addition to in kdelibs.ebuild, and now kde not only compiles, but xfree86 4.2 and kde 3.0.3 both work! i'm a gentoo n00bie, and it took me two days shy of four weeks to get gentoo up to a desktop from a 1.4rc1r2 stage 1 cd. there were lots of problems, but i was able to do it thanks to lots of help from people like you. i hope you are able to get the USE flag for --enable-final into the gentoo release. i just made a small donation to gentoo.org and noted on the payment that it was in thanks for your help. thank you again. your help was the key to getting gentoo up and running for me.
You're welcome :-) Update: I suggested such a new use flag on -core. Drobbins suggested that I read /proc/meminfo in the ebuilds to decide whether to use --enable-final or not, since its effect on the compiled output is practically nil. That makes sense if I do it correctly, since with a use flag I'd still get bugreports like this one and have to tell people to disable the use flag. I think a criterion around >=256 mb ram, >=512 mb ram+swap is reasonable. I'll try to measure the actual mem usage.
The code has been in place for some time now, only using enable-fnal if there is >=200MB free mem. We are also considering disabling enable-fnal by default entirely.
