| Summary: | gcc crashes frequently when compiling almost anything, such as gcc itself, mozilla and various other stuff. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marco <feedback> |
| Component: | [OLD] GCC Porting | Assignee: | Please assign to toolchain <gcc-porting> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | blocker | CC: | mholzer, morfic, pee |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Marco
2003-10-19 11:30:52 UTC
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 |
