When compiling fluxbox-0.9.11 on a K6-2, GCC hangs on the file Screen.cc, filling all availiable memory incluing swap. Reproducible: Always Steps to Reproduce: 1.emerge fluxbox 2.wait... 3.Kill it before it eats all availiable memory. Actual Results: All 64MB of core plus 512MB of swap filled. Screen.cc not compiled Expected Results: I believe that Screen.cc should have made it past compilation Gentoo Base System version 1.4.16 Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.10-gentoo-r1-NerdWare i586) ================================================================= System uname: 2.6.10-gentoo-r1-NerdWare i586 AMD-K6(tm) 3D processor Python: dev-lang/python-2.3.4 [2.3.4 (#1, Oct 24 2004, 02:42:32)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.14.90.0.8-r1 sys-devel/libtool: 1.5.2-r5 virtual/os-headers: 2.4.21-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="" ARCH="x86" AUTOCLEAN="yes" BASH_ENV="/etc/spork/is/not/valid/profile.env" CC="gcc" CFLAGS="-O2 -march=k6-2 -pipe" CHOST="i686-pc-linux-gnu" CLEAN_DELAY="5" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CVS_RSH="ssh" CXX="g++" CXXFLAGS="-O2 -march=k6-2 -pipe" DISTDIR="/usr/portage/distfiles" EDITOR="/bin/nano" FEATURES="autoaddcvs autoconfig candy ccache distlocks keepwork sandbox sfperms" FETCHCOMMAND="/usr/bin/wget -t 5 --passive-ftp -P ${DISTDIR} ${URI}" GENTOO_MIRRORS="http://192.168.2.1/gentoo/" GLIBC_SSP_CHECKED="1" GRP_STAGE23_USE=" acl berkdb gpm ipv6 ncurses nls pam perl python readline ssl tcpd " HOME="/root" HOSTNAME="tej" INFODIR="/usr/share/info" INFOPATH="/usr/share/info:/usr/share/gcc-data/i386-pc-linux-gnu/3.3/info" INPUTRC="/etc/inputrc" LESS="-R" LESSOPEN="|lesspipe.sh %s" LOGNAME="root" MAIL="/var/mail/root" MAKEFLAGS="-j1" MAKEOPTS="-j2" MANPATH="/usr/share/man:/usr/local/share/man:/usr/share/gcc-data/i386-pc-linux-gnu/3.3/man" NOCOLOR="false" OLDPWD="/var/tmp/portage/xorg-x11-6.8.1.901" PAGER="/usr/bin/less" PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i386-pc-linux-gnu/gcc-bin/3.3" PKGDIR="/usr/portage/packages" PORTAGE_ARCHLIST="alpha amd64 arm hppa ia64 m68k mips ppc ppc64 ppc-macos ppc-od s390 sh sparc x86 x86-fbsd x86-obsd x86-od" PORTAGE_BINHOST_CHUNKSIZE="3000" PORTAGE_CALLER="emerge" PORTAGE_GID="250" PORTAGE_MASTER_PID="28990" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PRELINK_PATH="" PRELINK_PATH_MASK="" PS1="\[\033[01;31m\]\h \[\033[01;34m\]\W \$ \[\033[00m\]" PWD="/root" RESUMECOMMAND="/usr/bin/wget -c -t 5 --passive-ftp -P ${DISTDIR} ${URI}" RPMDIR="/usr/portage/rpm" RSYNC_RETRIES="3" RSYNC_TIMEOUT="180" SHELL="/bin/bash" SHLVL="1" SYNC="rsync://192.168.2.1/portage" TERM="linux" USE="x86 X acl apache2 apm arts avi bash-completion berkdb bitmap-fonts bootsplash bzip2 bzlib cap chroot codecs crypt css cups dga dnd dvd encode escreen fb fbcon fbdev font-server foomaticdb fortran gdbm gif gimpprint gmail gpm gtk gtk2 ipv6 jpeg latex libwww mad mikmod mng motif mozcalendar mozilla mozsvg mozxmlterm mpeg msdav mysql mysqli ncurses nethack nls nptl ntlm ocaml oggvorbis opengl oscar oss pam pcntl pcre pdflib perl php png pthreads python quicktime readline samba sdl session sftplogging silverxp slang smime sockets spell spl ssl svga szip tcpd tetex tiff tokenizer transcode truetype truetype-fonts usb wmf xchattext xine xml2 xmms xv xvid zeo zlib" USER="root" USERLAND="GNU" USE_EXPAND="VIDEO_CARDS INPUT_DEVICES LINGUAS" XARGS="xargs -r" _="/usr/bin/emerge" -------------- Note... the IP addresses are for my local network, which includes a distfiles mirror and an rsync mirror. Unfortunately, I have Cable internet, so I get approximately 1kbps uplad, so I'm not able to be an official mirror.
*** This bug has been marked as a duplicate of 76524 ***
I beg to differ... 76524 has an actual error. This hangs, with no output whatsoever until you run out of memory. Also, it seems to fail with any version of Flux... and ALWAYS on Screen.cc, which is very odd. I won't reopen it, because I respect your closing it. However, I do ask you to reconsider.
It's the same deal. Screen.cc makes extensive use of templates, which need rather a lot of RAM to compile properly, and have a tendency to die horribly if you're overclocking / have dodgy RAM.
