During GCC's install process, it builds "fixed" headers and places them into /usr/lib/gcc-lib/${CHOST}/${PV}/include/. One example is the net-snmp headers. Say net-snmp is 5.0.8 when you build gcc, then it will copy those headers and place them into that folder. now you upgrade net-snmp and the old headers still exist and over-ride the new headers, which breaks anything that depends on the new version of the headers as the "fixed" old version is pulled in instead.
This also occurs with the openssl headers when upgrading 0.9.6 to 0.9.7.
see bug 13795 for the openssl breakage. as a suggested fix, could we please have GCC not install it's "fixed" headers if possible?
i don't know whether my problem is related, but i'm using gcc-3.2.3-r1 and it fails to compile almost any ebuild (reproducible, tested with kernel 2.4.22 and 2.6.0-test7). it also fails to compile gcc-3.2.3-r2, so i'm stuck now! what can i do? any work-around/quickfix? help greatly appreciated. for me, this bug is definitely a *blocker*.
daniel: i seriously doubt your problem is related to this. I suggest getting a suitable livecd copying over the gcc+binutils tbz2 packages and then installing those to your system.
Daniel: unzip a stage 3 tarball in a directory, chroot, build a gcc package, copy it over and emerge -K it.
the reason for my problem: kernel 2.6.0-test7 was broken (see thread http://www.ussg.iu.edu/hypermail/linux/kernel/0310.1/1748.html) currently i'm emerging gcc with 2.4.22 again and so far it works (must have been bad luck when i tested it with 2.4.22 and it didn't work) sorry for bothering.
this occured with slang too. i had to put something in the slang ebuild to remove those "fixed" headers to prevent breaking other slang apps (linking the wrong version headers with libraries)
I know about this issue. It have bitten us with ncurses, slang, openssl and possibly others I have forgotten. I am not however sure if just removing them is the sane thing to do though.
Definely not removing the entire directory is required, as GCC puts some of it's own headers there. I think we should just disable the fixincludes stage that builds the header files for the moment, experimentally, and see if it causes breakages with anything. From what i've read, we are quite unlikely to hit breakages by not running it on 32-bit linux platforms. 64 bit linux platforms require some more care, so possibly leave it enabled for them still.
I have this in my local tree, and will commit in ~ if it checks out ok: -- --- gcc-3.3.2-r2.ebuild 2003-11-02 15:28:03.000000000 +0200 +++ gcc-3.3.2-r2.ebuild 2003-11-02 14:02:15.000000000 +0200 @@ -357,13 +357,26 @@ } src_install() { + local x= + local tmp= + # Do allow symlinks in ${LOC}/lib/gcc-lib/${CHOST}/${PV}/include as # this can break the build. - for x in cd ${WORKDIR}/build/gcc/include/* + for x in ${WORKDIR}/build/gcc/include/* do if [ -L ${x} ] then rm -f ${x} + continue + fi + done + # Remove generated headers, as they can cause things to break + # (ncurses, openssl, etc). + for x in `find ${WORKDIR}/build/gcc/include/ -name '*.h'` + do + if grep -q 'It has been auto-edited by fixincludes from' ${x} + then + rm -f ${x} fi done
no arguments with that patch.
azarah: is there a timeline for that patch going in?
*** Bug 33630 has been marked as a duplicate of this bug. ***
bump azarah: please apply this asap.
*** Bug 36020 has been marked as a duplicate of this bug. ***
Would it make sense to just 'emerge gcc' to fix on a broken system? Assuming of course that the 'emerge gcc' doesn't fail. I ack that 'emerge gcc' would take quite awhile to run, but it would regenerate headers based on current setup. ??
great, i see this is in gcc-3.3.2-r4 and r5 now. marking as fixed. my virtual/snmp will move along when one of the gcc ebuilds hits stable.
*** Bug 38935 has been marked as a duplicate of this bug. ***
*** Bug 38985 has been marked as a duplicate of this bug. ***
*** Bug 38748 has been marked as a duplicate of this bug. ***
*** Bug 39140 has been marked as a duplicate of this bug. ***
*** Bug 31338 has been marked as a duplicate of this bug. ***
*** Bug 32565 has been marked as a duplicate of this bug. ***
*** Bug 38829 has been marked as a duplicate of this bug. ***
*** Bug 39840 has been marked as a duplicate of this bug. ***
*** Bug 39866 has been marked as a duplicate of this bug. ***
How would the pathces applied work for people running stable? I'm running stable, and the entire install process blocks on 'ttmkfdir'. That is to say, the base system is installed, but it's impossible to install Xfree. FYI the stable version og gcc is now gcc-3.2.3-r3.
bfg: try to tag gcc-3.2.3-r4 as x86 and check that it works for you. the only change over 3.2.3-r3 is this patch.
*** Bug 40338 has been marked as a duplicate of this bug. ***
*** Bug 46119 has been marked as a duplicate of this bug. ***
i have nearly the same problem as Daniel. i have gcc-3.3.5-r1, i have changed USE flag yesterday to add 'nls' to have a utf-8 compatible system. Since than, i have problems compiling some packages (I didn't know what to do after changing a USE flag so i didn't (couldn't) do anything at first). then i've learned that i should run 'emerge --update --deep --newuse world'. i've tried it, it compiled some packages but when it came to gcc-3.3.5-r1, there was an error. I'm not sure if this is a bug or not and I don't know what to do now. any help appreciated.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f40c02ae8c70eca848890d38010b2776f856bb1a commit f40c02ae8c70eca848890d38010b2776f856bb1a Author: Sam James <sam@gentoo.org> AuthorDate: 2024-12-16 19:44:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-12-25 10:01:22 +0000 sys-libs/glibc: run fixincludes in pkg_postinst We enabled fixincludes for a window between GCC 13 and whatever the just released version of glibc was at the time to cover Float128 changes. We then turned it off again when it was (mostly) no longer needed. (Though arguably it was/still is needed for some upgrade paths or combinations and maybe we should reconsider that given we now have a proper solution here to "defanging" fixincludes (as it turns out we were kind of using it wrong, see bug #30701)). Anyway, for any glibc installed during that window, a fixincludes'd pthread.h would've been installed to the include-fixed directory, which then becomes a cached stale copy when the rest of glibc changes like: ``` --- pthread.h-fixincludes 2024-12-12 06:49:06.918089635 +0000 +++ /usr/include/pthread.h 2024-12-06 16:49:09.306028087 +0000 [...] @@ -232,7 +223,7 @@ the thread in *THREAD_RETURN, if THREAD_RETURN is not NULL. */ extern int pthread_tryjoin_np (pthread_t __th, void **__thread_return) __THROW; -# ifndef __USE_TIME_BITS64 +# ifndef __USE_TIME64_REDIRECTS ``` because the guards no longer match up with the rest of glibc. The fix is for us to refresh fixincludes using `mkheaders` (if available) which we weren't installing until recently (7d99be77433bf10fb0ce6fc99c7b40de700ed650) in pkg_postinst for sys-libs/glibc. We will likely need to add similar logic into linux-headers at least too. I am considering adding such an update to gcc-config too. Note that we also have to cover the case where mkheaders isn't available *but* a cached broken pthread.h exists, so if mkheaders doesn't exist, but pthread.h does in include-fixed, we move that away to .bak. Bug: https://gcc.gnu.org/PR20166 Bug: https://gcc.gnu.org/PR94089 Bug: https://gcc.gnu.org/PR107059 Bug: https://gcc.gnu.org/PR118009 Bug: https://bugs.gentoo.org/30701 Bug: https://bugs.gentoo.org/933282 Tested-by: Matt Jolly <kangie@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.40-r7.ebuild | 23 +++++++++++++++++++++++ sys-libs/glibc/glibc-9999.ebuild | 23 +++++++++++++++++++++++ 2 files changed, 46 insertions(+)
