Summary: | sys-devel/gcc-4.x (ALL 4.x) freezes when compiling | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Menno Schaap <menno.schaap> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | loki_val, stefan.andreas.bauer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Menno Schaap
2009-05-10 18:10:33 UTC
Please try other versions of sandbox (older and newer). Is the problem still present for gcc-4.4.0? (In reply to comment #1) > Please try other versions of sandbox (older and newer). Is the problem still > present for gcc-4.4.0? > I will try different sandbox version (or compile one without it). It is still present with 4.4.0. I will keep you posted. Thanks (In reply to comment #1) > Please try other versions of sandbox (older and newer). Is the problem still > present for gcc-4.4.0? OUTPUT without errors, just frozen at "source compiled" ========================================================= /mnt/big/tmp/portage/sys-devel/gcc-4.1.2/work/build /mnt/big/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2 >>> Source compiled. ========================================================== I tried gcc-4.1.2 and 4.4.0 with sandbox-1.9, sandbox-1.4 and formerly sandbox-1.6-r2; no luck.. Thanks for the suggestion anyway!!! Just a guess, but is CONFIG_SYSVIPC set in the running kernel? If you've got /proc/config.gz enables, you can do: zcat /proc/config.gz |grep CONFIG_SYSVIPC To see. (In reply to comment #4) > Just a guess, but is CONFIG_SYSVIPC set in the running kernel? > If you've got /proc/config.gz enables, you can do: > zcat /proc/config.gz |grep CONFIG_SYSVIPC > To see. > Thanks for the suggestion!!!! @usr/src/linux $ grep SYSVIPC .config CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y PROOF THAT THE EMERGE IS IN FACT SUCCESFUL, IS RUNNING EBUILD AFTERWARDS: #ebuild /usr/portage/sys-devel/gcc/gcc-4.1.2.ebuild compile >>> Existing ${T}/environment for 'gcc-4.1.2' will be sourced. Run 'clean' >>> to start with a fresh environment. * gcc-4.1.2-uclibc-patches-1.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... * [ ok ] * gcc-4.1.2-patches-1.3.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... * [ ok ] * gcc-4.1.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... * [ ok ] * checking ebuild checksums ;-) ... * [ ok ] * checking auxfile checksums ;-) ... * [ ok ] * checking miscfile checksums ;-) ... * [ ok ] * checking gcc-4.1.2-uclibc-patches-1.0.tar.bz2 ;-) ... * [ ok ] * checking gcc-4.1.2-patches-1.3.tar.bz2 ;-) ... * [ ok ] * checking gcc-4.1.2.tar.bz2 ;-) ... * [ ok ] >>> Checking gdc-0.24-src.tar.bz2's mtime... >>> Checking gcc-4.1.2-uclibc-patches-1.0.tar.bz2's mtime... >>> Checking gcc-4.1.2-patches-1.3.tar.bz2's mtime... >>> Checking gcc-4.1.2.tar.bz2's mtime... >>> WORKDIR is up-to-date, keeping... >>> It appears that 'gcc-4.1.2' is already compiled; skipping. >>> Remove '/mnt/big/tmp/portage/sys-devel/gcc-4.1.2/.compiled' to >>> force compilation. (In reply to comment #6) Could you post the output of: emerge -pv coreutils which tee It might be some oddity in tee ( info from bug 186278 ) that's causing this. (In reply to comment #7) > (In reply to comment #6) > > Could you post the output of: > emerge -pv coreutils [ebuild R ] sys-apps/coreutils-7.1 USE="acl nls -caps -gmp (-selinux) -static -vanilla -xattr" > which tee /usr/bin/tee > It might be some oddity in tee ( info from bug 186278 ) that's causing this. > I hope I posted al info you need, I do not exactly understand the role of tee in this. Could I post something else or recompile coreutils or a different version? Quite a sharp look of suspecting tee from 186278 ;-) Thanks again! I had one "emerge gcc" running, which was frozen, relevant "ps aux" listed below (tee was not in the proces list). Perhaps this helps? root 19099 0.0 0.2 6272 2732 tty1 SN+ 20:35 0:00 /bin/bash /usr/lib/portage/bin/ebuild.sh compile root 19120 0.0 0.3 7040 3120 tty1 SN+ 20:35 0:00 /bin/bash /usr/lib/portage/bin/ebuild.sh compile root 20190 0.0 0.1 4900 1300 tty1 SN+ 20:45 0:00 /bin/sh root 21314 0.0 0.1 5328 2008 tty1 SN+ 20:35 0:00 make -j2 LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O LIBPATH=/usr/lib/gcc/i686-pc-linux-gnu/4.3.2 BOOT_CFLAGS= -march=athlon-xp -O2 -pipe bootstrap-lean I guess the problem is a segfault during the compile. Running down /var/log/messages, the only segfaults I find is during compilation of gcc. I do not believe in hardware problems since "world" compiles fine, including heavy packages. Looked like glibc related. I upgraded glibc, but look at the last line: May 9 20:47:49 karel fixincl[14627]: segfault at 40020000 ip 400aa133 sp bfa9dc4c error 4 in libc-2.8.so[40039000+134000] May 10 09:54:13 karel fixincl[23831]: segfault at 40020000 ip 400aa133 sp bf86c31c error 4 in libc-2.8.so[40039000+134000] May 13 18:59:33 karel fixincl[13982]: segfault at 40022000 ip 400aa133 sp bfc1b19c error 4 in libc-2.8.so[40039000+134000] May 13 20:45:30 karel fixincl[20165]: segfault at 40020000 ip 400aa133 sp bf95ea2c error 4 in libc-2.8.so[40039000+134000] May 14 06:31:39 karel fixincl[11901]: segfault at 40020000 ip 400aa133 sp bf99ca0c error 4 in libc-2.8.so[40039000+134000] May 14 19:05:29 karel fixincl[14780]: segfault at 40020000 ip 400aa133 sp bfda000c error 4 in libc-2.8.so[40039000+134000] May 14 19:34:03 karel fixincl[16510]: segfault at 4024d000 ip 400b9133 sp bf8ce29c error 4 in libc-2.8.so[40048000+134000] May 14 21:29:49 karel fixincl[11249]: segfault at 40254000 ip 400ba5e3 sp bfc2620c error 4 in libc-2.9.so[40049000+137000] The problem occured with glibc-2.8, as well as glibc-2.9 (glibc-2.9_p20081201) Does this help any further? The problem seems to isolate around "fixincludes", as can be read in the Temporary Build directory: TMPDIR/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/fixincludes From the README some information, however, this is too lowlevel for me... GCC MAINTAINER INFORMATION ========================== If you are having some problem with a system header that is either broken by the manufacturer, or is broken by the fixinclude process, then you will need to alter or add information to the include fix definitions file, ``inclhack.def''. Please also send relevant information to gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org and, please, to me: bkorb@gnu.org. To make your fix, you will need to do several things: 1. Obtain access to the AutoGen program on some platform. It does not have to be your build platform, but it is more convenient. 2. Edit "inclhack.def" to reflect the changes you need to make. See below for information on how to make those changes. 3. Run the "genfixes" shell script to produce a new copy of the "fixincl.x" file. 4. Rebuild the compiler and check the header causing the issue. Make sure it is now properly handled. Add tests to the "test_text" entry(ies) that validate your fix. This will help ensure that future fixes won't negate your work. 5. Go into the fixinc build directory and type, "make check". You are guaranteed to have issues printed out as a result. Look at the diffs produced. Make sure you have not clobbered the proper functioning of a different fix. Make sure your fix is properly tested and it does what it is supposed to do. 6. Now that you have the right things happening, syncronize the $(srcdir)/tests/base directory with the $(builddir)/tests/res directory. The output of "make check" will be some diffs that should give you some hints about what to do. 7. Rerun "make check" and verify that there are no issues left. Thanks for looking into this!
> May 14 21:29:49 karel fixincl[11249]: segfault at 40254000 ip 400ba5e3 sp
> bfc2620c error 4 in libc-2.9.so[40049000+137000]
>
> The problem occured with glibc-2.8, as well as glibc-2.9 (glibc-2.9_p20081201)
>
FYI:
Compiling with or without glibc-omitfp made no difference
Tried now gcc-4.4.0 again with CFLAGS AND CXXFLAGS="" got a segfault of fixincludes again, but without reference to glibc: fixincl[3725]: segfault at 40254000 ip 08056994 sp bfa56e30 error 4 in fixincl[8048000+1b000] What does Error code 4 mean? Thanks. I can't reproduce this, and it if was a real failure with the package, others would be running into this as well. I'm guessing it is some sort of hardware issue on your system. I have a similar error fixincl[7876]: segfault at 2baa37b7a000 ip 0000000000409fc8 sp 00007fff72fc4910 error 4 in fixincl[400000+1a000] I have good reason to believe that this is caused by a corrupt file somewhere in my system. >
> I have good reason to believe that this is caused by a corrupt file somewhere
> in my system.
>
I think you are right. I have this problem for almost 2 years now without a clue. I have ran emerge -a (!!) system and world and the problem still persists.
I can finish the " emerge -a " builds but only with --skip-first, after a failed gcc built. I am not getting any further on this. I have re-read the upgrade guide for upgrading from gcc-3.4 to 4.x, muddled with GCC_SPECS and so on. But no change.
I doubt that it is hardware related since " emerge -a world " works fine, except for gcc. Even openoffice builds without problems...
If you find anything useful please let me know. Thanks!
Seems to be related to #278895. Actually, more specifically I meant that I believed an include (a .h), is corrupt and fixincl crashes on 'fixing' it. I can't quite remember whether I had any solid evidence of this though. |