Bugzilla Bug 20600

This is the compilation failure metabug. If your bugreport was marked a
duplicate of this one, it means the gentoo developers consider your problem to
be local to your setup. Look below for symptoms, causes and possible cures.

The compilation failure that cause a bug to be marked duplicate of this one can
be one of the following:
- internal compiler errors or gcc segfaults. These are caused by gcc. We are
  sorry, but we cannot do anything about those.

- Random segfaults during compilation. These are signalled by compilation
  failing at undetermined points. Often trying to recompile will succesfully
  compile the file it was complaining about, but will fail for another. This is
  in general a sign of hardware problems.

- Segfaults in auxiliary tools used in the compilation process. Some merges fail
  on segmentation faults in auxiliary tools. When those tools are stable
  themselves (bugs with the tools themselves should not be marked duplicate of
  this bug) the causes are often the same as for gcc problems.

There are multiple causes that can cause the above symptoms:
- Flaky hardware. This is showstopper number one. The cause can be either:
  - Insufficient power supply. To detect this try to unplug as many auxiliary
    devices (like cd-players, usb devices, etc.)  as possible and see whether
    the problem persists
  - Overclocked memory or CPU's can show random anomalous behaviour. Worse some
    hardware has these problems even at "factory speed". Lowering the clockspeed
    would be the solution to this problems
  - Overheated CPU's. CPU's have several calculation units which have a specific
    location on the chip. Compilation tends to intensively use a few of those
    units. This can cause heat problems within these units even when the overall
    chip temperature is within limits. If overheating is a problem a better cpu
    cooler often works. (Underclocking also works as heat increases with
    frequency)
  - Broken chipsets. There are some chipsets on motherboards which are broken.
    sometimes the os (read linux kernel) can work around some of these bugs,
    sometimes the only solution is a new motherboard.
- Overagressive compilation flags. There are many possible combinations of
  compilation flags. Some of them are problematic with some software by design,
  others contain bugs that are triggered by certain sources. In general the
  higher the optimization the more likely it is to hit a bug. If things work
  with CFLAGS="-O2 -mcpu=<yourcpu>" then this is your problem.
  Of particular note here is that there still are bugs in gcc-3.2.2's code
  generation with -march=pentium4. (If you have a pentium4 try to compile with
  CFLAGS="-march=pentium3 -mcpu=pentium4, if things work then, report it as in
  that case we can automatically filter -march=pentium4 for the package
  involved)
- Instable kernel. There is no guaranty for stability of the many kernels gentoo
  offers. Trying to use the vanilla kernel with conservative options can show
  whether you've hit a kernel bug. Especially kernel-preemption and low latency
  can cause problems with certain combinations of options (esp. hardware
  drivers)

Compilation flags should work. If you find a certain compilation flag that
doesn't work, look it up in the gcc manual (info gcc) and read whether it is
concidered safe to use in this case. In case it is considered safe you might
file a bug with the gcc developers.

Mark the bug as CANTFIX as we cannot resolve these problems. Additional
comments, suggestions, possible causes and possible solutions are welcome as
comments.

*** Bug 14412 has been marked as a duplicate of this bug. ***

*** Bug 14864 has been marked as a duplicate of this bug. ***

*** Bug 15072 has been marked as a duplicate of this bug. ***

*** Bug 15410 has been marked as a duplicate of this bug. ***

*** Bug 18920 has been marked as a duplicate of this bug. ***

*** Bug 10988 has been marked as a duplicate of this bug. ***

*** Bug 11968 has been marked as a duplicate of this bug. ***

*** Bug 15898 has been marked as a duplicate of this bug. ***

*** Bug 16233 has been marked as a duplicate of this bug. ***

*** Bug 16886 has been marked as a duplicate of this bug. ***

*** Bug 19909 has been marked as a duplicate of this bug. ***

*** Bug 20716 has been marked as a duplicate of this bug. ***

*** Bug 20822 has been marked as a duplicate of this bug. ***

*** Bug 22420 has been marked as a duplicate of this bug. ***

*** Bug 22509 has been marked as a duplicate of this bug. ***

*** Bug 21375 has been marked as a duplicate of this bug. ***

*** Bug 21949 has been marked as a duplicate of this bug. ***

*** Bug 24300 has been marked as a duplicate of this bug. ***

*** Bug 26769 has been marked as a duplicate of this bug. ***

*** Bug 29195 has been marked as a duplicate of this bug. ***

*** Bug 26976 has been marked as a duplicate of this bug. ***

Old Bug, should be marked. CANTFIX.

*** Bug 23001 has been marked as a duplicate of this bug. ***

*** Bug 33808 has been marked as a duplicate of this bug. ***

*** Bug 33716 has been marked as a duplicate of this bug. ***

*** Bug 36181 has been marked as a duplicate of this bug. ***

*** Bug 30054 has been marked as a duplicate of this bug. ***

 It can be fault of dirty hardware. It can be I think also a problem of raised
voltage from power station. Normally in Poland there was 220 V and now it is
230. The power supply in computer (in Poland of course) is designed to take
220V. I thing higher volatage can rise the speed of linear rising of the signal
in CPU clock and make the CPU frequency faster, then (cause the processor is
running in funny frequency) hazards can occur (as said below). Good resolve
should be a voltage converter. And fuck up the Polish politics for changing the
Voltage only for buying the power from Western Europe (we have enough power
stations). 

*** Bug 27508 has been marked as a duplicate of this bug. ***

*** Bug 39714 has been marked as a duplicate of this bug. ***

 The time showed that my motherboard was broken.

*** Bug 40524 has been marked as a duplicate of this bug. ***

*** Bug 43677 has been marked as a duplicate of this bug. ***

*** Bug 50159 has been marked as a duplicate of this bug. ***

*** Bug 47283 has been marked as a duplicate of this bug. ***

*** Bug 50907 has been marked as a duplicate of this bug. ***

*** Bug 50418 has been marked as a duplicate of this bug. ***

*** Bug 57221 has been marked as a duplicate of this bug. ***

*** Bug 58698 has been marked as a duplicate of this bug. ***

*** Bug 43276 has been marked as a duplicate of this bug. ***

*** Bug 61155 has been marked as a duplicate of this bug. ***

*** Bug 61671 has been marked as a duplicate of this bug. ***

*** Bug 61994 has been marked as a duplicate of this bug. ***

*** Bug 62174 has been marked as a duplicate of this bug. ***

*** Bug 63690 has been marked as a duplicate of this bug. ***

*** Bug 64954 has been marked as a duplicate of this bug. ***

*** Bug 37142 has been marked as a duplicate of this bug. ***

*** Bug 59493 has been marked as a duplicate of this bug. ***

*** Bug 64560 has been marked as a duplicate of this bug. ***

*** Bug 66477 has been marked as a duplicate of this bug. ***

*** Bug 66722 has been marked as a duplicate of this bug. ***

*** Bug 68927 has been marked as a duplicate of this bug. ***

*** Bug 69089 has been marked as a duplicate of this bug. ***

*** Bug 60411 has been marked as a duplicate of this bug. ***

*** Bug 74319 has been marked as a duplicate of this bug. ***

*** Bug 74913 has been marked as a duplicate of this bug. ***

*** Bug 75506 has been marked as a duplicate of this bug. ***

As an additional note to this bug, some packages exhibit these problems
significently more often than others. The compile of MySQL-4* really stresses
the hardware, and in particular two files in it are much worse than others:
sql_yacc.*, item_sum.*

The former is a very large and complex file generated from yacc source data,
and both of them put the optimization in GCC to it's fully potential.
I've seen machines that pass memtest86, cpuburn and every other test I can
throw at them, but fail if anything more than -O0 is used for compiling
sql_yacc.o.

*** Bug 76524 has been marked as a duplicate of this bug. ***

*** Bug 77268 has been marked as a duplicate of this bug. ***

*** Bug 77944 has been marked as a duplicate of this bug. ***

*** Bug 79178 has been marked as a duplicate of this bug. ***

*** Bug 79974 has been marked as a duplicate of this bug. ***

*** Bug 79973 has been marked as a duplicate of this bug. ***

I discovered the cause of this problem for me.

The computer case sits on the floor with the cover off.  Upon inspection the HSF was clogged with dust and the thermal compound had pretty much disappeared from between the HSF and the CPU.

Cleaned the dust out and re-thermal compounded the HSF/CPU and everything has been fine ever since.

Not that this is an OLD K6/500 box that has been in operation for at least 5 years now.

*** Bug 77860 has been marked as a duplicate of this bug. ***

*** Bug 80938 has been marked as a duplicate of this bug. ***

I had many problems with Intel machines beginning from Pentium 3 800Mhz 
ending at Pentium 75. Some compilations never succeded, especcialy >=gcc-3.3.1. 
My AMD processors done it fine (Duron 1600, even AMD K6-2 300), I thought it was
somenthing from Intel. But then I discovered both AMD's had at least 192MB of 
RAM. It was it, when I put some spap to my Pentium 75 (overclocked for 133)
machine wich has 64MB of RAM, to make his operational memory over 192MB he compiled
everything I wanted (even faster that I though it should). Pentium 3 have had only
128MB and I never could succesfully acomplish bootstrap.sh or emerge system (when 
starting from stage2). I hadn't have the possibility of checking if giving more
RAM will work, case the motherboard started to hang very often and when I was 
trying to clean the dust from it, I scratched the processors surface. but I 
thing it could work. (I think that corruption of motherboard was fault of 
voltage rise from 220V to 230V in Poland, when central and eastern european 
countries joined Europe Union)
 So check if you have enough memory to end the compilation.
Another thing is that, that CFLAGS and CXXFLAGS are weakly described in manual.
I proposing to use:
"-Os or -O2" for machines with small cache (under 128kb)
"-O2" for machines with cache about 256kb
"-O3" for machines with big cache - 512kb and more.
CFLAGS should be: "-march=<machine> -pipe -Wall -s -fomit-frame-pointer"
CXXFLAGS should be: "-march=<machine> -pipe -Wall -s -fno-rtti -fexceptions"
doing bootstrap.sh and emerge system processes.
When db4 will be compiled one can change "-fexceptions" to "-fno-exceptions"
I heard the code is then faster, but I din't saw the difference so I'm using 
-fexceptions, case there was no ebuild that wanten from me no-exceptions.
I  See how it works and you will know if it is good for you to change or not to 
change -fexceptions flag.
 When someting isn't compilling corectly sometimes -mpcu=<machine> flag will 
help (for example Flight Gear Flight Simulator doesn't still compile on march)
and sometimes you should disable -fno-rtti but bigger part of ebuilds will compile.
 And last thing. When using -march put names of your special instructions in USE 
flags, for example - when using -march=athlon-xp put: USE="[...] mmx mmx2 3dnow 
3dnowex 3dnow2 sse" then ebuild will know what should they compile in binary.
Thats all for now.

Please please, do not use "-fno-rtti -fexceptions" Both these flags are
application specific. They turn of standard c++ features. THIS WILL ONLY WORK
if the application in question does not use those features. Applications that
use them (i.e. use c++ as it is supposed to be used) will fail in all kinds of
strange ways. Never do this globally, and only locally if you are the author of
the software.

btw. If your motherboard gets corrupted because of the voltage switch this can
only mean one thing: A power supply that is at or over the edge of it's
operating parameters. The 10 volt diference is within the normal tollerance of
power supplies. If however the power demand is allready higher than it can
handle, things can break. Please remember in this that overclocking means you
also use more power.

 I overclocked the Pentium processor, Pentium 3 was untouched. I thought it is
a fault of higher voltage case condensators on the motherboard were bulbed.
 About flags: I'm using them both, most of sotfware compiles, maybe "-fno-rtti"
isn't needed, but db4 will compile only with "-fexceptions" turned on, of
course. When I was writing that comment I forgot, you can change the settings
localy for selected package in /etc/portage/package.use, sorry for that. 
Maybe this should be done automatically somewhere - to make the boostrap.sh and
emerge system processes easier?

You can't cflags in /etc/portage/package.use, only through hacks in
/etc/portage/bashrc. But they are NOT SAFE IN ANY CASE and not recommended.

About the power supply. Your motherboard does not run on 220/230 volts, but on
a lower voltage (I believe, but don't pin me on it 12 volts). Depending on your
power supply this is a clean dc current with little variance at 12 volts, or a
less than clean supply around 12 volts. Good power converters have electronic
circuits that stabilize the voltage. That makes them able to cope with the
change in voltage between 220/230. Most power supplies are even designed for
multiple voltages to make export easier. (My printer has a power supply that
can handle input ranges from 110 volts to 230)

*** Bug 80655 has been marked as a duplicate of this bug. ***

*** Bug 81597 has been marked as a duplicate of this bug. ***

*** Bug 82079 has been marked as a duplicate of this bug. ***

*** Bug 82307 has been marked as a duplicate of this bug. ***

*** Bug 82432 has been marked as a duplicate of this bug. ***

*** Bug 82829 has been marked as a duplicate of this bug. ***

*** Bug 83423 has been marked as a duplicate of this bug. ***

*** Bug 83457 has been marked as a duplicate of this bug. ***

*** Bug 83533 has been marked as a duplicate of this bug. ***

*** Bug 83986 has been marked as a duplicate of this bug. ***

*** Bug 85006 has been marked as a duplicate of this bug. ***

*** Bug 85711 has been marked as a duplicate of this bug. ***

I run the ASUS 266-D with dual AMD MP 2800s and by default they run ~2ghz on
266mhz bus. Until reading this post, gcc was segfaulting inconsistently durring
build. I then rebooted, went to my bios and dropped cpu speed to ~1.6ghz, gcc
then built flawlessly.

*** Bug 87856 has been marked as a duplicate of this bug. ***

*** Bug 88125 has been marked as a duplicate of this bug. ***

*** Bug 91237 has been marked as a duplicate of this bug. ***

*** Bug 58969 has been marked as a duplicate of this bug. ***

*** Bug 94591 has been marked as a duplicate of this bug. ***

I think there are two things mixed in this bug which shouldn't be mixed: It is 
probably true that things like "internal error: Segmentation fault" or other 
illegal instructions are due to flaky hardware/bad memory/overclocking/heat 
problems etc. 
However, the other thing also included in this bug is the systematic filling 
of memory which eventually ends in "internal error: killed" - it is hard to 
imagine that a hardware problem can cause the kernel or some basic library to 
consider memory as reserved, and, moreover, to do this rather reproducible and 
without *ever* hitting some illegal instruction or exhibiting some other 
strange behaviour (and moreover, doing this same thing in x86 and amd64 modes 
and independent of temperature/clock rate and the compilation flags of the 
used kernel/gcc/other libraries (and with kernels/kernel configurations)). 
This sounds to me much more like a *software* bug in the kernel or gcc or some 
basic library which apparently (for some unknown reason) only shows up in some 
architectures. Unfortunately, I am running out of ideas of how to locate this 
bug. Any hints are appreciated (or also an explanation why this might be a 
hardware problem anyway). 
 

*** Bug 95391 has been marked as a duplicate of this bug. ***

*** Bug 96480 has been marked as a duplicate of this bug. ***

*** Bug 97583 has been marked as a duplicate of this bug. ***

*** Bug 98157 has been marked as a duplicate of this bug. ***

*** Bug 100013 has been marked as a duplicate of this bug. ***

*** Bug 100159 has been marked as a duplicate of this bug. ***

*** Bug 98392 has been marked as a duplicate of this bug. ***

*** Bug 101430 has been marked as a duplicate of this bug. ***

*** Bug 101547 has been marked as a duplicate of this bug. ***

*** Bug 99342 has been marked as a duplicate of this bug. ***

*** Bug 101750 has been marked as a duplicate of this bug. ***

*** Bug 101736 has been marked as a duplicate of this bug. ***

*** Bug 101769 has been marked as a duplicate of this bug. ***

*** Bug 101933 has been marked as a duplicate of this bug. ***

*** Bug 102318 has been marked as a duplicate of this bug. ***

*** Bug 102390 has been marked as a duplicate of this bug. ***

*** Bug 103408 has been marked as a duplicate of this bug. ***

*** Bug 104684 has been marked as a duplicate of this bug. ***

*** Bug 104984 has been marked as a duplicate of this bug. ***

*** Bug 104984 has been marked as a duplicate of this bug. ***

*** Bug 105006 has been marked as a duplicate of this bug. ***

*** Bug 105350 has been marked as a duplicate of this bug. ***

*** Bug 105840 has been marked as a duplicate of this bug. ***

*** Bug 106632 has been marked as a duplicate of this bug. ***

*** Bug 106647 has been marked as a duplicate of this bug. ***

*** Bug 107050 has been marked as a duplicate of this bug. ***

*** Bug 107279 has been marked as a duplicate of this bug. ***

*** Bug 107750 has been marked as a duplicate of this bug. ***

*** Bug 80905 has been marked as a duplicate of this bug. ***

*** Bug 108563 has been marked as a duplicate of this bug. ***

*** Bug 108750 has been marked as a duplicate of this bug. ***

*** Bug 108490 has been marked as a duplicate of this bug. ***

*** Bug 109539 has been marked as a duplicate of this bug. ***

*** Bug 107793 has been marked as a duplicate of this bug. ***

*** Bug 109821 has been marked as a duplicate of this bug. ***

*** Bug 110283 has been marked as a duplicate of this bug. ***

*** Bug 98445 has been marked as a duplicate of this bug. ***

*** Bug 111538 has been marked as a duplicate of this bug. ***

*** Bug 113720 has been marked as a duplicate of this bug. ***

*** Bug 112467 has been marked as a duplicate of this bug. ***

*** Bug 114590 has been marked as a duplicate of this bug. ***

*** Bug 114691 has been marked as a duplicate of this bug. ***

*** Bug 114773 has been marked as a duplicate of this bug. ***

*** Bug 89320 has been marked as a duplicate of this bug. ***

*** Bug 103874 has been marked as a duplicate of this bug. ***

*** Bug 92144 has been marked as a duplicate of this bug. ***

*** Bug 109779 has been marked as a duplicate of this bug. ***

*** Bug 115520 has been marked as a duplicate of this bug. ***

*** Bug 111488 has been marked as a duplicate of this bug. ***

*** Bug 87784 has been marked as a duplicate of this bug. ***

*** Bug 116841 has been marked as a duplicate of this bug. ***

*** Bug 117045 has been marked as a duplicate of this bug. ***

*** Bug 117430 has been marked as a duplicate of this bug. ***

*** Bug 117411 has been marked as a duplicate of this bug. ***

*** Bug 117893 has been marked as a duplicate of this bug. ***

*** Bug 118154 has been marked as a duplicate of this bug. ***

removed me from CC

*** Bug 108540 has been marked as a duplicate of this bug. ***

*** Bug 119194 has been marked as a duplicate of this bug. ***

*** Bug 119424 has been marked as a duplicate of this bug. ***

*** Bug 119780 has been marked as a duplicate of this bug. ***

*** Bug 119920 has been marked as a duplicate of this bug. ***

*** Bug 122509 has been marked as a duplicate of this bug. ***

*** Bug 123871 has been marked as a duplicate of this bug. ***

remove me from cc

*** Bug 124062 has been marked as a duplicate of this bug. ***

*** Bug 124935 has been marked as a duplicate of this bug. ***

Remove me from CC list.

*** Bug 123871 has been marked as a duplicate of this bug. ***

*** Bug 126937 has been marked as a duplicate of this bug. ***

*** Bug 127168 has been marked as a duplicate of this bug. ***

*** Bug 127130 has been marked as a duplicate of this bug. ***

*** Bug 127514 has been marked as a duplicate of this bug. ***

*** Bug 128013 has been marked as a duplicate of this bug. ***

*** Bug 128573 has been marked as a duplicate of this bug. ***

*** Bug 127855 has been marked as a duplicate of this bug. ***

*** Bug 129243 has been marked as a duplicate of this bug. ***

*** Bug 129305 has been marked as a duplicate of this bug. ***

Runnning out of resources is another think which can cause this.
Things to check:
-Sufficent free memory
This can be calculated by the root directory of the program times about 3.
-File descriptors
Just make sure you don't have over 500-600 files being written to or read from

*** Bug 130318 has been marked as a duplicate of this bug. ***

*** Bug 130990 has been marked as a duplicate of this bug. ***

Other possible case: out of memory.  My swap was broken and the compilation ran
out of memory (128MB RAM).  Swap fixed, problem solved.  Good luck to all.

(In reply to comment #173)
> Other possible case: out of memory.  My swap was broken and the compilation ran out of memory (128MB RAM).  Swap fixed, problem solved.  Good luck to all.

Yeah, that's true.. Btw, 

- Random segfaults during compilation. These are signalled by compilation
failing at undetermined points. Often trying to recompile will succesfully
compile the file it was complaining about, but will fail for another. This is
in general a sign of hardware problems.

// No, this is in general a sign of GCC 4.1 - problem ;-)

*** Bug 131790 has been marked as a duplicate of this bug. ***

*** Bug 132232 has been marked as a duplicate of this bug. ***

*** Bug 132412 has been marked as a duplicate of this bug. ***

*** Bug 132568 has been marked as a duplicate of this bug. ***

*** Bug 135372 has been marked as a duplicate of this bug. ***

*** Bug 135593 has been marked as a duplicate of this bug. ***

*** Bug 136190 has been marked as a duplicate of this bug. ***

*** Bug 136450 has been marked as a duplicate of this bug. ***

*** Bug 136007 has been marked as a duplicate of this bug. ***

*** Bug 136754 has been marked as a duplicate of this bug. ***

*** Bug 136989 has been marked as a duplicate of this bug. ***

*** Bug 137360 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> Mark the bug as CANTFIX as we cannot resolve these problems. Additional
> comments, suggestions, possible causes and possible solutions are welcome as
> comments.
> 
it has compiled now for me with any "use flag" and with -march=pentium4 instead
of -march=prescott =)

*** Bug 138342 has been marked as a duplicate of this bug. ***

*** Bug 139183 has been marked as a duplicate of this bug. ***

*** Bug 139461 has been marked as a duplicate of this bug. ***

*** Bug 139829 has been marked as a duplicate of this bug. ***

*** Bug 139752 has been marked as a duplicate of this bug. ***

*** Bug 140749 has been marked as a duplicate of this bug. ***

*** Bug 141297 has been marked as a duplicate of this bug. ***

*** Bug 141511 has been marked as a duplicate of this bug. ***

*** Bug 141511 has been marked as a duplicate of this bug. ***

*** Bug 142137 has been marked as a duplicate of this bug. ***

*** Bug 142272 has been marked as a duplicate of this bug. ***

> Bug 142272 has been marked as a duplicate of this bug
Upgrading my RAM from 128MB to 512MB fixed this problem.

*** Bug 139328 has been marked as a duplicate of this bug. ***

*** Bug 142861 has been marked as a duplicate of this bug. ***

*** Bug 143153 has been marked as a duplicate of this bug. ***

*** Bug 143406 has been marked as a duplicate of this bug. ***

*** Bug 143501 has been marked as a duplicate of this bug. ***

*** Bug 144424 has been marked as a duplicate of this bug. ***

*** Bug 142529 has been marked as a duplicate of this bug. ***

*** Bug 95276 has been marked as a duplicate of this bug. ***

*** Bug 145623 has been marked as a duplicate of this bug. ***

*** Bug 145720 has been marked as a duplicate of this bug. ***

*** Bug 145916 has been marked as a duplicate of this bug. ***

*** Bug 146034 has been marked as a duplicate of this bug. ***

*** Bug 146141 has been marked as a duplicate of this bug. ***

*** Bug 146312 has been marked as a duplicate of this bug. ***

*** Bug 147510 has been marked as a duplicate of this bug. ***

*** Bug 147834 has been marked as a duplicate of this bug. ***

*** Bug 149070 has been marked as a duplicate of this bug. ***

*** Bug 149667 has been marked as a duplicate of this bug. ***

*** Bug 149780 has been marked as a duplicate of this bug. ***

*** Bug 149950 has been marked as a duplicate of this bug. ***

*** Bug 89086 has been marked as a duplicate of this bug. ***

*** Bug 150418 has been marked as a duplicate of this bug. ***

*** Bug 150512 has been marked as a duplicate of this bug. ***

The UK used to be 240, we stepped down to 230...
All computers I know of run on DC (12V , 5V etc) which is why you need a PSU,
sounds like yours needs replacing :-)

(In reply to comment #29)
>  It can be fault of dirty hardware. It can be I think also a problem of raised
> voltage from power station. Normally in Poland there was 220 V and now it is
> 230. The power supply in computer (in Poland of course) is designed to take
> 220V. I thing higher volatage can rise the speed of linear rising of the signal
> in CPU clock and make the CPU frequency faster, then (cause the processor is
> running in funny frequency) hazards can occur (as said below). Good resolve
> should be a voltage converter. And fuck up the Polish politics for changing the
> Voltage only for buying the power from Western Europe (we have enough power
> stations). 
> 

*** Bug 153029 has been marked as a duplicate of this bug. ***

*** Bug 153557 has been marked as a duplicate of this bug. ***

*** Bug 154046 has been marked as a duplicate of this bug. ***

*** Bug 154141 has been marked as a duplicate of this bug. ***

*** Bug 154990 has been marked as a duplicate of this bug. ***

*** Bug 155110 has been marked as a duplicate of this bug. ***

*** Bug 155423 has been marked as a duplicate of this bug. ***

*** Bug 155611 has been marked as a duplicate of this bug. ***

*** Bug 155678 has been marked as a duplicate of this bug. ***

*** Bug 155817 has been marked as a duplicate of this bug. ***

*** Bug 155968 has been marked as a duplicate of this bug. ***

*** Bug 156441 has been marked as a duplicate of this bug. ***

*** Bug 156333 has been marked as a duplicate of this bug. ***

*** Bug 157363 has been marked as a duplicate of this bug. ***

*** Bug 158272 has been marked as a duplicate of this bug. ***

*** Bug 158644 has been marked as a duplicate of this bug. ***

*** Bug 158805 has been marked as a duplicate of this bug. ***

*** Bug 159709 has been marked as a duplicate of this bug. ***

*** Bug 159709 has been marked as a duplicate of this bug. ***

*** Bug 164464 has been marked as a duplicate of this bug. ***

I've managed to work around this by replacing my compilers with scripts that
call the real compilers and then call them a second time in the event of a
failure.  I also added a "sleep $DELAY" as well so that I can emerge things
with "DELAY=3 emerge whatever" to give the CPU a few seconds to rest between
each execution of GCC.  I also tried simply a 90 second delay before the second
attempt at compiling, but that proved problematic as it seems configure scripts
attempt to compile a lot of stuff that is expected to fail. 

*** Bug 165503 has been marked as a duplicate of this bug. ***

*** Bug 167474 has been marked as a duplicate of this bug. ***

*** Bug 168350 has been marked as a duplicate of this bug. ***

*** Bug 170444 has been marked as a duplicate of this bug. ***

*** Bug 171059 has been marked as a duplicate of this bug. ***

*** Bug 173154 has been marked as a duplicate of this bug. ***

*** Bug 176430 has been marked as a duplicate of this bug. ***

*** Bug 179010 has been marked as a duplicate of this bug. ***

*** Bug 185352 has been marked as a duplicate of this bug. ***

*** Bug 185626 has been marked as a duplicate of this bug. ***

*** Bug 186250 has been marked as a duplicate of this bug. ***

*** Bug 189736 has been marked as a duplicate of this bug. ***

*** Bug 190169 has been marked as a duplicate of this bug. ***

My 2 cents contrib about the power supply issue. As Paul said above, 230V is
inside the tolerance of a 220V power supply (typically +10 -15%, the same
tolerance as the power line). 

Things can go wrong if the power get to 230V + 15%. It will be outside the
tolerance of the power supply. But I have never seen this to append. Most
(all?) of the time, the power line will be somewhere between 230V and 230V
-15%.

Another issue is money. It cost money to make a power supply, and for the same
amount of manufactured power supplies, it will be cheaper to make one model for
220-230V (or 220-240V), as one model for 220V and another one for 230V.

And most power supply are very cheap today. That bring the last problem:
quality. A cheap power supply (or whatever cheap electronic) will always be
made with cheap components. The number one problem in the power supply is the
electrolytic capacitors. They are aging very fast, and cheaper they are, faster
their characteristics are decreasing. I will not go into technical details, but
a computer power supply is all about charging and decharging very fast such
capacitors. They are doing the hardest work in the supply.  

Siemens, one of the best electrolytic manufacturer, is manufacturing many
different qualities of those components. At different prices of course. For
their best quality, they state at such a component must be changed in any case
after ten years of work if we want to be sure of its characteristic. No
testing, just to change it! We can not expect at we will get the same lifetime
from the same component coming from one at least 20 time less expensive brand.

(Don't buy old electrolytic capacitors, they are becoming dry when they do
nothing. And the dry electrolytic will not like at all when you will plug the
power in. Siemens state about half lifetime after one year of non activity for
its best quality.)

*** Bug 190462 has been marked as a duplicate of this bug. ***

*** Bug 192461 has been marked as a duplicate of this bug. ***

*** Bug 193813 has been marked as a duplicate of this bug. ***

*** Bug 194998 has been marked as a duplicate of this bug. ***

*** Bug 196287 has been marked as a duplicate of this bug. ***

*** Bug 198819 has been marked as a duplicate of this bug. ***

*** Bug 198521 has been marked as a duplicate of this bug. ***

*** Bug 199728 has been marked as a duplicate of this bug. ***

*** Bug 200416 has been marked as a duplicate of this bug. ***

*** Bug 201729 has been marked as a duplicate of this bug. ***

*** Bug 201954 has been marked as a duplicate of this bug. ***

*** Bug 204894 has been marked as a duplicate of this bug. ***

*** Bug 206080 has been marked as a duplicate of this bug. ***

*** Bug 208083 has been marked as a duplicate of this bug. ***

*** Bug 209131 has been marked as a duplicate of this bug. ***

*** Bug 212839 has been marked as a duplicate of this bug. ***

*** Bug 213230 has been marked as a duplicate of this bug. ***

*** Bug 217320 has been marked as a duplicate of this bug. ***

I've upgraded my RAM from 64M to 192M and increased swap space from 128M to 1G,
now everything works fine. Thanks Jakub!

*** Bug 218910 has been marked as a duplicate of this bug. ***

*** Bug 219878 has been marked as a duplicate of this bug. ***

*** Bug 216922 has been marked as a duplicate of this bug. ***

Today I started undervolting my pentium m cpu. When I tried to compile firefox
gcc segfaulted, tried again, gcc segfaulted again. Now I raised all my voltages
(the lower ones) with about 32 mV and firefox is compiling again.

Summary: an undervolted cpu can seem to run fine but you're never sure until
you run into problems.

*** Bug 229939 has been marked as a duplicate of this bug. ***

*** Bug 232952 has been marked as a duplicate of this bug. ***

*** Bug 231218 has been marked as a duplicate of this bug. ***

*** Bug 237325 has been marked as a duplicate of this bug. ***

Was having segfault issue on my fileserver today. Turned out my CMOS had gotten
cleared yesterday, fixed the issue by setting my memory timings to the most
aggressive my motherboard would support. Go figure

*** Bug 259662 has been marked as a duplicate of this bug. ***

*** Bug 199033 has been marked as a duplicate of this bug. ***

(In reply to comment #29)
>  It can be fault of dirty hardware. It can be I think also a problem of raised
> voltage from power station. Normally in Poland there was 220 V and now it is
> 230. The power supply in computer (in Poland of course) is designed to take
> 220V. 
It is due to unifying voltage/frequency in whole EU, don't blame politicans.

> Good resolve should be a voltage converter.
You should use devices which comply some standarts and not devices build "on
knees". I live in CZ near borders with PL and I had bad experiences with
(cheap) broadband TV antennas from Poland.

£Another issue with the power line is the phase between the voltage and the
current (called power factor or charge factor). Normally, the dephasing must be
equal to 0, but in practice, you will get almost always a little dephasing. If
you are living at the country or in a place where the line have a very long
distance, or you are using a lot of cheap extension cords, you can get a
dephasing that will be outside the tolerance.

If it is the case, no one single manufacturer will give you a guaranty that its
devices will or can work fine.

For a general discussion one this issue on power lines, see 
http://en.wikipedia.org/wiki/Power_factor

*** Bug 263624 has been marked as a duplicate of this bug. ***