A way to solve it would sometimes be to "weaken" the CFLAGS (by omitting -O3 or -pipe, or just by putting --mcpu="i686") but it just overrides the problem that usually persists. I get the following errors Internal error: Killed (Program cc1) Internal error: Killed (Program cc1plus) I'm sure that the crash probability is > 50%. Reproducible: Always Steps to Reproduce: 1. emerge gcc or 1. emerge mozilla or 1. emerge epiphany Actual Results: I got the same errors. Expected Results: Maybe they should have compiled cleanly... Portage 2.0.49-r13 (default-x86-1.4, gcc-3.3.1, glibc-2.3.2-r6, 2.4.22) ================================================================= System uname: 2.4.22 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.3.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /var/bind /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs sandbox buildpkg ccache distcc userpriv usersandbox notitles noclean noauto cvs keeptemp keepwork" GENTOO_MIRRORS="http://gentoo.linux.no/ http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo/ http://www.fhh.opensource-mirror.de/gentoo.org/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://ftp6.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.inode.at/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/root/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 oss apm avi crypt cups encode foomaticdb gif jpeg libg++ mad mikmod mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib directfb alsa gdbm berkdb slang readline arts tetex aalib bonobo svga ggi tcltk java guile X sdl gpm tcpd pam libwww ssl perl python esd imlib oggvorbis gnome gtk qt motif opengl mozilla cdr aavm activefilter cjk dedicated doc dvb dvd evms2 fbcon gtk2 gtkhtml hyriand ipv6 minimal mysql odbc offensive plotutils usagi X509 xinerama -kde -ldap"
How much ram do you have in this box?
256MB - DDRAM Feel free to ask for clarification/details!
how much swap space do you have? is it active? what are the powersupply ratings for 3.3V/5V/12V (brand of powersupply?) internal compiler errors can be caused by hardware instabilities and checking if swap is being used and if you have enough of it never hurts
It is a NEW error, and I have not changed ANYTHING, maybe some 'emerge world' has messed something up... I use ACCEPT_KEYWORDS="~x86" Could it be releated to "unstable" packages?
Running unstable typically means one accepts the possibility that the world may very well end by emerging a specific package, however this is not usually the case. Why gcc crashes for you is a very big mystery....There's not a lot of information provided to really ascertain the likely cause. Off the top of my head, low ram is usually the #1 cause with gcc, simply because it's a memory beast, especially when compiling large source files. Maybe ram you have has bad timing values, Not sure. Other things like the PSU already mentioned can also play a role. I would give gcc-3.3.2 a shot, and see if gcc still fails for you. If it does, I recommend build an entire new system in a chroot to see if gcc still fails. If it does, then I would suspect a hardware issue. If it doesn't, then I would suspect some odd setting in your system messing with gcc.
I'm having the same problems starting today. I installed from a livecd last night, and built up quite a bit of the system in chroot. This is on a new R40 thinkpad, 1g ram, 1g swap. I rebooted into system w/o chroot, upgraded to current gcc (3.2.3-r2?) and tried to compile mozilla. It segfaults. I also tried 2.5 kernel compile from BK, same thing. Having gcc compile it self fails also I changed CFLAGS from -O3 -pipe -funroll-loops -mcpu=686, to just -O2 -mcpu=pentium3, and tried to recompile mozilla, no love. re-emerged gcc with -O2 -mcpu=pentium3, it finishes the emerge with these flags. I can also compile linux from bk with this gcc. Kernel boots fine. Something is goofy with the default CLFAGS/gcc ;p
I'm starting to believe there is something fundamentally b0rked about gcc-3.2.3-r2. There's been way too many reports of that package hosing people's systems or just not building anymore. Hopefully we can get 3.3.x rolled out soon.
did you all who report issues start from stage3 tarballs? still using default cflags on many of your packages? http://mygentoo.kicks-ass.net/cflags download this script its a perl script you can run as user, make it executable and run 'cflags -a' let me know if many of your system critical parts like glibc dont match your cflags at all for a athlon-xp stage3 tarball that would be matching: -O3 -fprefetch-loop-arrays -funroll-loops -march=athlon-xp -pipe sorry not sure what the i686/P3/P4 default to try -O2 -march-athlon-xp -fomit-frame-pointer -pipe see if you get gcc and glibc to recompile and then try compiling anything else with those NOTE: those cflags are a little tamer and less bloated than the default ones and if you have no hardware issues should work nicely (dont use those on anything but athlon-xp/mp) also run memtest86 from livecd making sure your mem is ok try running burnK7 to test cpu stability, run this only if you can monitor your machine's temperatures as it will get your CPU hotter than any compile ever did both could help rule out hardware issues again burnK7 should not be run if you can not monitor your system's temperatures 2.4 kernel users can emerge i2c and lm_sensors 2.6 kernel users can compile in i2c suport in their kernels, mkdir /sys (upon reboot it will be mounting /sys which has the i2c sensors in it) emerge gkrellm 2.1.21 which has support for /sys i2c sensors on 2.6 kernel let me know if the cflags helped, if your emerging of gcc/glibc segfaults just start it again, till both are merged with those cflags then try more and more of the packages that used to fail and report back if or if not they still fail (please only if you ran memtest and burnK7 successfully for prolonged time)
try memtest86 and cpuburn maybe it's a faulty hardware
closing
