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.
