gcc crashes during build with the error (summarized): /usr/include/pthread.h:655: error: array type has incomplete element type Fix: pthread.h has #include <bits/setjmp.h> when this is changed to #include <setjmp.h> the affected file compiles. Reproducible: Always Steps to Reproduce: 1.emerge gcc-4.0.0_alpha20050213.ebuild 2. 3.
These fixes are probably more appropriate, and complete: http://sourceware.org/ml/libc-hacker/2005-02/msg00000.html The patch is in the link. I'll test it later to make sure it works with our current snapshot.
Apparently the patch above in comment #1 does not work completely. I'll try to work on this more later.
Created attachment 52503 [details, diff] GCC 4 compile fix This should allow you to compile glibc with the newest snapshot of GCC4 in Portage. Please test to make sure I didn't horribly break anything.
Since this is all fixes to glibc, could the summary be changed to reflect this?
Oh alright
Just a comment to say that even with this patch, glibc compiles fine with gcc 3.3 and 3.4.
*** Bug 84605 has been marked as a duplicate of this bug. ***
I've added this patch to my localpatchset, and if all goes well, I'll add it in when -r1 is unmasked in the next few days.
Ok, it's in now. Thanks for the help.
gcc-4 alphas beyond 20050130 still fail to build for me (not sure about 0130 now, just succeeded with it quite some time ago). ./xgcc -B./ -B/usr/i686-pc-linux-gnu/bin/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -L/var/tmp/portage/gcc-4.0.0_beta20050305/work/build/gcc/../ld -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I/var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc -I/var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/. -I/var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/../include -I/var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/../libcpp/include -fvisibility=hidden -DHIDE_EXPORTS -fexceptions -c /var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from /var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/gthr-posix.h:43, from ./gthr-default.h:1, from /var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/gthr.h:114, from /var/tmp/portage/gcc-4.0.0_beta20050305/work/gcc-4.0-20050305/gcc/unwind-dw2.c:42: /usr/include/pthread.h:664: error: array type has incomplete element type make[3]: *** [libgcc/./unwind-dw2.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/gcc-4.0.0_beta20050305/work/build/gcc' make[2]: *** [libgcc.a] Error 2 make[2]: Leaving directory `/var/tmp/portage/gcc-4.0.0_beta20050305/work/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-4.0.0_beta20050305/work/build/gcc' make: *** [profiledbootstrap] Error 2 !!! ERROR: sys-devel/gcc-4.0.0_beta20050305 failed. !!! Function gcc_do_make, Line 1171, Exitcode 2 !!! make failed with profiledbootstrap !!! If you need support, post the topmost build error, NOT this status message. Why is the patch applied as part of 5040_all_2.3.4-gcc4.patch, which is excluded from the patchset if the compiler isn't gcc4, therefore making it totally useless in the first place? [[ $(gcc-major-version) == "4" ]] || GLIBC_PATCH_EXCLUDE="${GLIBC_PATCH_EXCLUDE} 5040_all_2.3.4-gcc4.patch" I compile glibc with 3.4.3 of course (not with 4.0.0alpha-20050130 that I do have installed in addition), therefore $(gcc-major-version) == "4" check should return 0, the second part of OR is evaluated and therefore the 5040_all_2.3.4-gcc4.patch excluded and the fix is inside that patch....
You are looking at it wrong - that line means: if its not gcc-4, exclude the patch (or that is what should be happening with that logic).
That's exactly how I was looking at it. I am trying to install the gcc4 compiler, and logically I am trying to upgrade glibc and install gcc4 with the previous version of the compiler - 3.4.x. The patch is excluded (as glibc is not being compiled with gcc-4, which I can't get before I succesfully install a fixed glibc), glibc isn't fixed, and I can't install gcc4 in the first place, for the patch to ever be included. There should be no condition on the gcc version for that particular glibc patch, not talking about all the other file diffs inside the gcc4 specific patch.
Ok, so the patch is needed for gcc-4.x to compile, and not to compile glibc with gcc-4.x ? Sorry, did not read the whole thing, or worked with the bug.
It appears the background of this larger patch was to make glibc compile with gcc4, but one little part of this, namely: - extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROW; + extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROW; is necessary for gcc4 to build (with glibc), not glibc to build with gcc4. Every gcc4 snapshot in portage beyond 20050130 has failed to compile on my NPTL-only/gcc-3.4.x system. Now I hand-edited /usr/include/pthread.h to change __env[1] to *__env and so far the gcc4 upgrade is doing good. Hasn't errored yet, and if the problem is there still it should have encountered it quite some minutes ago. I need gcc4 to work on things as a developer, not use the fortunately already installed older _snapshot_ of gcc4 to install the single-most important library on the system. But I believe we all like upstream bugzillas, so the relevant bugzilla link: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166 It talks about a workaround in gcc4 for the glibc problem, in the end is a fixinclude for glibc, as far I can decipher, does that little array to pointer patch.
This patch was to fix all of the errors associated with glibc and gcc4. Yes, the one header is needed to compile gcc. I am not certain why it is only conditionally applied, to upgrade to gcc4, one would need that header patched in order to compile gcc.
----- - extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROW; + extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROW; ----- Hmm, that is wrong. Or in the context of the original anyhow - this should be closer: ----- - extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROW; + extern int __sigsetjmp (struct __jmp_buf_tag *(__env + 1), int __savemask) __THROW; -----
Although it looks wonky in the first place.
Urk, dont worry, im still sleeping.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=787
*** Bug 85707 has been marked as a duplicate of this bug. ***
*** Bug 86248 has been marked as a duplicate of this bug. ***
I'm still getting this here.
Because its not been fixed. Get a hold of eradicator and check why he applies that patch conditionally ...
I was applying it conditionally because I thought it was the cause of the segfault headaches... I was incorrect there, and I think we can remove the conditional in -r2 once az's patch gets cleaned up =)
Apparently is not my patch either :/ http://bugs.gentoo.org/show_bug.cgi?id=85555#c77 I added a simple test for both (idea from mike), so hopefully we will just get die messages, and not hosed systems from now on.
*** Bug 87293 has been marked as a duplicate of this bug. ***
*** Bug 88219 has been marked as a duplicate of this bug. ***
some words on bug-report duplication: I did *not* honor this bug report here, because its topic is: "glibc fails to compile with gcc-4.0" that is, that glic failes to compile with gcc-4.0, I mean, it tells me, that I should have gcc-4 already installed and I am trying to compile glibc (that fails to compile with gcc-4.) I know, it's really early in the morning already here (4:56am), but this is really odd anyway. So, the exact fix (as actually reported in my bug report) is the following extract from the attachment one of you made. diff -ur glibc-2.3.4-orig/nptl/sysdeps/pthread/pthread.h glibc-2.3.4/nptl/sysdeps/pthread/pthread.h --- glibc-2.3.4-orig/nptl/sysdeps/pthread/pthread.h 2005-03-02 17:50:28.000000000 -0500 +++ glibc-2.3.4/nptl/sysdeps/pthread/pthread.h 2005-03-02 16:58:54.000000000 -0500 @@ -1,4 +1,4 @@ -/* Copyright (C) 2002, 2003, 2004 Free Software Foundation, Inc. +/* Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -661,7 +661,7 @@ /* Function used in the macros. */ struct __jmp_buf_tag; -extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROW; +extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROW; /* Mutex handling. */ Though, the topic shall be "gcc-4.0 fails to compile due glibc issues)" and noth the other way around. Having a look at the other changes in the patch, I must say, that they rather look like code cleanups and little typo fixes (RESOLVE/RESOLVE_MAP) and are somewhat unrelated to the current issue (yet still not unimportant anyway). g'n8, Christian Parpart.
Like I said, the one fix is needed to get gcc4 to compile. The other patches don't really matter at this point since there are other breakages in glibc that are only fixed in the latest snapshots. With the newer snapshots of gcc4, you'll need a newer snapshot of glibc if you want to recompile glibc. I'm running the glibc snapshot from 4/4 without problems. One patch is needed for binutils to support the AS_NEEDED stuff the newer glibc's use.
*** Bug 88368 has been marked as a duplicate of this bug. ***
it's applied now in -r1 glibc
*** Bug 89998 has been marked as a duplicate of this bug. ***
*** Bug 90029 has been marked as a duplicate of this bug. ***
*** Bug 90212 has been marked as a duplicate of this bug. ***
I've tried to compile gcc 4.0.0 (after re-emerging glibc 2.3.4.20041102-r1), and I got the error mentioned in comment #10. So, which -r1 version does comment #31 refer to ?
Jo
Joël, I assumed he meant the latest -r1, which is 2.3.4.20050125-r1. My gcc-4 worked after I rebuilt it.
It worked, thanks Aaron !
*** Bug 94610 has been marked as a duplicate of this bug. ***
*** Bug 88395 has been marked as a duplicate of this bug. ***
