Fighting gcc 3.2 again.

kaiyi lin kaiyilin at
Tue Oct 29 09:01:41 PST 2002

Thanks a lot for infos. Right, when just a few transistors go
wrong, whatever kind of electronic failure, it can lead to some
unstable behaviour of PC. If I active Memory Parity check in Bios
can it be possible solution or improvement in this case?!

Overheat, I think, affects much more on RAM than on CPU. RAM
can be very sensitive to temperature, working enviroment of electronic

Bill Maltby - LFS Related wrote:
> On Tue, 29 Oct 2002, Kaiyi Lin wrote:
>>One question. If it is a CPU heat problem the PC should hang, right?
>>Why just a compilation error?
> Please remember I *know* nothing about hardware, so some more
> knowledgeable people on the list would be better sources to answer your
> question. But having said that... I will fill the room with hot air now.
> :)
> You are beyond my expertise with that question. But, from what little
> understanding I have, the failure modes for electronic components are not
> only one, like locking up. AFAIK, as the boundaries of reliabe operation
> are approached, various types of "breakdown" in individual transistor
> operations can occur. In not sure if this is a complete failure of the
> node, or sporadic correct operation or what. Regardless, depending on
> which transistors fail, and I *guess* how they fail, the result could be
> other than lock up.
> On very old equipment, I have seen invalid data results, but everything
> looked like it was working OK. It was tough to find those errors. Didn't
> know if it was disk, memory, software or what. And when we turn the
> machine off and open it, everything cools down. :-\
> Keep in mind, I only *think* it may be heat related. If you have good
> indications that it is something else, you should investigate that because
> you are on site and have access to the units.
> One last thing. If memory serves, there is some "aging" of electronic
> components that occurs over time. IIRC, it was mentioned for memory. From
> what I remember, that could cause perfectly good components to degrade
> just enough so that (for example) when the room was cool, all worked OK
> and when the room warmed up just a few degrees, these components became
> unreliable.
> Please remember I *know* nothing about hardware, so some more
> knowledgeable people on the list would be better sources to answer your
> question.
>>Bill Maltby - LFS Related wrote:
>>>On Mon, 28 Oct 2002, kaiyi lin wrote:
>>>>Na, just complete chapter5 and starting chapter6.
>>>>After lucky feeling of long glibc compiling with great expectation
>>>>to finish gcc 3.2 installation in chapter 6 today. But it seems that
>>>>compiling gcc is the biggest problem in my LFS I got the following
>>>>segmentation errors
>>>Did you remember to apply the patch? I'm not sure if this is related or
>>>>./xgcc -B./ -B/usr/i586-pc-linux-gnu/bin/ -isystem
>>>>/usr/i586-pc-linux-gnu/include -isystem
>>>>/usr/i586-pc-linux-gnu/sys-include -O2  -DIN_GCC    -W -Wall
>>>>-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem
>>>>./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
>>>>-D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../gcc-3.2/gcc
>>>>-I../../gcc-3.2/gcc/. -I../../gcc-3.2/gcc/config
>>>>-I../../gcc-3.2/gcc/../include  -DL_lshrdi3 -c
>>>>../../gcc-3.2/gcc/libgcc2.c -o libgcc/./_lshrdi3.o
>>>>../../gcc-3.2/gcc/libgcc2.c: In function `__lshrdi3':
>>>>../../gcc-3.2/gcc/libgcc2.c:266: internal error: Segmentation fault
>>>>Please submit a full bug report,
>>>>with preprocessed source if appropriate.
>>>>See <URL:> for instructions.
>>>>make[3]: *** [libgcc/./_lshrdi3.o] Error 1
>>>>make[3]: Leaving directory `/static/src/gcc-build/gcc'
>>>>make[2]: *** [libgcc.a] Error 2
>>>>make[2]: Leaving directory `/static/src/gcc-build/gcc'
>>>>make[1]: *** [stage2_build] Error 2
>>>>make[1]: Leaving directory `/static/src/gcc-build/gcc'
>>>>make: *** [bootstrap] Error 2
>>>>I have netscape running at the same time and one xterm windows while
>>>>Running K6-2 550 286M RAM
>>>If you just type the same make command it was running, it should pick up
>>>with the correct module and continue. It may fail again, but see if it is
>>>in a later module. If so, keep doing this and it will usually finish
>>>eventually. This works if the fault is related to heat, "flaky" hardware
>>>and so on. I had to do this on a 32MB AMD 5x86-133 one time. It worked.
>>>Later there were a couple of other packages that also requeired this
>>>procedure to make it through.

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list