The kde-base/kmail meta ebuild gets stuck when compiling libkmailprivate_la.all_cpp.cpp when the kdeenablefinal use flag is activated. Disabling the flag causes kmail to build properly. Perhaps my system does not have sufficient memory (512mb)? The ebuild does not crash outright ending in an error, but ps aux shows the gcc process compiling the file as defunct and sending a sig 2 (ctrl-C) to the ebuild terminates it cleanly. Reproducible: Always Steps to Reproduce: 1. Add 'kde-base/kmail kdeenablefinal' to /etc/portage/package.use. 2. Attempt rebuild of kmail: emerge --newuse kmail Actual Results: The compile will "get stuck" at libkmailprivate_la.all_cpp.cpp Expected Results: The compile should proceed normally and finish. Perhaps the kdeenablefinal flag for kde-base/kmail should be dropped? emerge --info: Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-cko4 x86_64) ================================================================= System uname: 2.6.11-cko4 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#2, Apr 25 2005, 11:42:07)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -Os -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -Os -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox strict" GENTOO_MIRRORS="http://gentoo.ccccom.com http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa arts berkdb bitmap-fonts crypt cups curl encode fam flac font-server fortran gdbm gif gpm imagemagick jp2 jpeg kde kdeenablefinal kdexdeltas lzw lzw-tiff mad mp3 ncurses nls nptl ogg oggvorbis opengl pam perl png python qt readline sdl ssl tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml2 xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Some more info: If left to continue in its "hung" state, there is a huge amount of memory being used (476548 VmSize, 257808 VMRSS) and the system is swapping heavily. I can't really tell if this is a memory leak in the compiling toolchain, or if this high consumption is legit.
Okay, the build DID eventually finish (took about 1.5 hours) and required the addition of some extra swap, but it did end up working. If this is reproducable, I still reccomend that kdeenablefinal be dropped from kde-base/kmail.
a) The flag cannot be dropped for one ebuild, it's global via eclass. b) If you don't have enough virtual ram, don't use the flag. It's not set by default.
