glibc compiling problem

[testor]

While doing "emerge -uva world" I get unexpected segfault when compiling glibc. Compilling interrupted with following message:

make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/sunrpc/xbootparam_prot.stmp] Segmentation fault

Maybe anybody have some solution?

[gruven]

Most segmentation faults I encounter while compiling large programs is either due to overheating, or bad hardware.

I will need to see more of the error code though. Also, does it happen in the same spot every time?

My bet is either heat, or bad memory.

[testor]

---
i386-pc-linux-gnu-gcc -nostdlib -nostartfiles -o /var/tmp/portage/sys-libs/glibc-2.5/wor
k/build-default-i386-pc-linux-gnu-linuxthreads/sunrpc/rpcinfo -Wl,-dynamic-linker=/lib/
ld-linux.so.2 -Wl,-z,combreloc -Wl,-z,relro /var/tmp/portage/sys-libs/glibc-2.5/work/
build-default-i386-pc-linux-gnu-linuxthreads/csu/crt1.o /var/tmp/portage/sys-libs/glibc-
2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/csu/crti.o `i386-pc-linux-gnu-gcc
--print-file-name=crtbegin.o` /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i38
6-pc-linux-gnu-linuxthreads/sunrpc/rpcinfo.o -Wl,-rpath-link=/var/tmp/portage/sys-libs/
glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads:/var/tmp/portage/sys-libs/gl
ibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/math:/var/tmp/portage/sys-libs
/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/elf:/var/tmp/portage/sys-li
bs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/dlfcn:/var/tmp/portage/sy
s-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/nss:/var/tmp/portage/
sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/nis:/var/tmp/portag
e/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/rt:/var/tmp/porta
ge/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/resolv:/var/tmp/
portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/crypt:/var/
tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/linuxth
reads /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthre
ads/libc.so.6 /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-l
inuxthreads/libc_nonshared.a -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed `i386-pc-
linux-gnu-gcc --print-file-name=crtend.o` /var/tmp/portage/sys-libs/glibc-2.5/work/build
-default-i386-pc-linux-gnu-linuxthreads/csu/crtn.o CPP='i386-pc-linux-gnu-gcc -E -x c-header' /var/tmp/portage/sys-libs/glibc-2.5/work/bui
ld-default-i386-pc-linux-gnu-linuxthreads/elf/ld-linux.so.2 --library-path /var/tmp/port
age/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads:/var/tmp/portag
e/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/math:/var/tmp/por
tage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/elf:/var/tmp/p
ortage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/dlfcn:/var/t
mp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/nss:/var
/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/nis:/v
ar/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/rt:/
var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/res
olv:/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthread
s/crypt:/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxth
reads/linuxthreads /var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-
gnu-linuxthreads/sunrpc/rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o /var/tmp/port
age/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-linuxthreads/sunrpc/xbootpar
am_prot.T
make[2]: *** [/var/tmp/portage/sys-libs/glibc-2.5/work/build-default-i386-pc-linux-gnu-l
inuxthreads/sunrpc/xbootparam_prot.stmp] Segmentation fault
make[2]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5/work/glibc-2.5/sunrpc'
make[1]: *** [sunrpc/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/sys-libs/glibc-2.5/work/glibc-2.5'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.5 failed.
Call stack:
ebuild.sh, line 1614: Called dyn_compile
ebuild.sh, line 971: Called qa_call 'src_compile'
environment, line 4082: Called src_compile
glibc-2.5.ebuild, line 1121: Called toolchain-glibc_src_compile
glibc-2.5.ebuild, line 235: Called die

!!! make for default failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.5/temp/build.l
og'.
---
I think there are no problem with hardware, because it's not first time when i compile really large application(such as gcc) - it was just one of planned system updates, which was successful. besides, I was do memtest86 for a couple of times when setting up this box. And it seems that compiling interrupts every time at the same point, but I'm not sure and rechecking this now..

May be for build such applications needs more memory? I have 256 main + 256 swap, this is enough? I have no X or other large application running. It's only pptpd running now, and it's not used by users at this moment.

[gruven]

Really, the only segmentation fault I got with gcc and good memory was when I was overclocking and my cpu got real hot.

If it is in the same spot every time, then it is a software bug. You may want to check on the gentoo forums if it happens every time in the same spot.

[testor]

I try to google about it, and google return to me one absoluty useless link. I never post to forums if I don't google before.

Also I retry compilation some times and got same error at the same point..

It seems that it not trivial hardware problem.

Do you have some other versions of possible reason of this fault? I haven't. Only solution that I see is to wait for a some time for a other versions, sync again and retry.. (at this moment system works perfect, glibc in only package that is not up to date, and this is not critical)

But what application faults in our situation? I think that it is ld, linker that is part of gcc, I'm right? Therefore recompiling of gcc itself can solve problem? It has any matter?

[testor]

Sorry, I don't know why, but google doesn't index this ( http://forums.gentoo.org/viewtopic-t-537944.html ) gentoo.org forum thread.

Thank you anyway!