Summary: | Update to gcc 3.3.6 does not update ld.so.conf | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexandre CLERICI <ganjo> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | dominik.buerkle, jakub |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexandre CLERICI
2005-09-07 05:52:20 UTC
*** Bug 105335 has been marked as a duplicate of this bug. *** I can confirm that /etc/ld.so.conf isn't correctly updated. I have installed gcc 3.3.6 and 3.4.3 and my default compiler is 3.3.6. My /etc/ld.so.conf is the following: /usr/local/lib /usr/lib/opengl/xorg-x11/lib /usr/i686-pc-linux-gnu/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130 /usr/lib/gcc/i686-pc-linux-gnu/3.4.3 /usr/lib/mozilla-firefox /usr/lib /opt/sun-jdk-1.4.2.08/jre/lib/i386/ /opt/sun-jdk-1.4.2.08/jre/lib/i386/native_threads/ /opt/sun-jdk-1.4.2.08/jre/lib/i386/classic/ /opt/sun-jdk-1.4.2.08/jre/lib/i386/server/ /usr/qt/3/lib /usr/kde/3.4/lib /usr/games/lib /usr/lib/fltk-1.1 /usr/lib/libstdc++-v3/ /usr/lib/octave-2.1.69 I have no problems with libs loading but it seems there is a problem in updating /etc/env.d/05gcc as it still contains a reference to the old gcc 3.3.5-20050130 PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3.6" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.3.6" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.3.6/info" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130:/usr/lib/gcc/i686-pc-linux-gnu/3.4.3" GCC_SPECS="" /etc/env.d/05gcc has the proper contents only after using gcc-config to switch gcc to 3.4.3 and then back to 3.3.6 anyone please check for this not to happen any more? It still happens when updating gcc-3.4.3-20050110 to gcc-3.4.4. THAT IS A SHOW STOPPER, GUYS !!! I *guess* this also happens on all platforms, but neither am I allowed to update the Platform (x86 => All) nor Priority (from P2 to P1), I regret. Check out Bug#88596 (libtool contains old compiler path), too! WORKAROUND: $ $EDITOR /etc/ld.so.conf replace the old gcc-version path by the new one -- don't mess with this file! ;-) $ ldconfig $ fix_libtool_files.sh $ gcc-config -l (very likely You will get a message similar to (1)) choose Your current compiler (You just emerged it, remember? ;-) $ gcc-config <number-of-compiler> $ emerge whatever... (1) partial output from "gcc-config -l": /usr/bin/gcc-config: line 497: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or directory * /usr/bin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110 ups, addition to WORKAROUND: $ emerge libtool $ emerge whatever... argh, after emerging libtool, another run of "fix_libtool_files.sh <oldversion>" seems to be necessary...??? Comparing output of fix_libtool_files.sh before and after emerging libtool makes me think that it didn't do anything before, this time it threw lots of "FIXING:" lines of output to me... So, in the workaround seems to be more like $ $EDITOR /etc/ld.so.conf replace the old gcc-version path by the new one -- don't mess with this file! ;-) $ ldconfig $ gcc-config -l (might complain "no such file...") choose Your current compiler (You just emerged it, remember? ;-) $ gcc-config <number-of-compiler> $ emerge libtool $ fix_libtool_files.sh <old-compiler-version> $ emerge whatever... Yes, one step beyond... ;-) Yeah, that's me... :-/ Forgot to mention "source /etc/profile" after gcc-config choice: ... $ gcc-config <number-of-compiler> $ . /etc/profile $ emerge libtool ... Same problem w/ upgrading to gcc-4.0.2 from an earlier pre version, does not update ld.so.conf and fails to run gcc-config. Confirmed by several users: http://forums.gentoo.org/viewtopic-p-2765179.html#2765179 http://forums.gentoo.org/viewtopic-p-2765325.html#2765325 Hi, as I read all those bugzillas, I never saw a report that's showing emerge messages of upgrades from x.x.x to y.y.y. Though there are a lot of claims like "me too, from x.x.x to y.y.y", I never saw a cut-n-paste of such error messages. The cut-n-paste messages were always of the form "x.x.x-datestamp" to y.y.y. So I believe it has something to do with the following lines in toolchain.eclass: local curr_config_ver if has_version 'app-admin/eselect-compiler' ; then curr_config_ver=$(env -i eselect compiler show ${CTARGET} | cut -f1 -d/ | awk -F - '{ print $5 }') else curr_config_ver=$(env -i gcc-config -c ${CTARGET} | awk -F - '{ print $5 }') fi where that "print $5" in awk is simply removing the "-datestring" appendix from e.g. 3.4.3-20050110. It would be caught by some awk script like awk '{ num=split( $0, ver, "-" ); if (num < 5) {exit 1}; printf( "%s", ver[5] ); for (i=6; i<=num; i++) {if (ver[i] ~ "^[[:digit:]._]*$") {printf( "-%s", ver[i] )} else {i=num} }; print ""; exit 0}; END {exit 1}' which also has the advantage that any unrecognized version-string also leads to a usable exit code (test $? -ne 0 => einfo, eerror). Try it with something like echo i686-pc-linux-gnu-3.4.4-20051021_03-132-bla-x | awk ... however, I also accept the underscore "_", if You don't want that then remove the one occurence in that awk line. I did not yet have time to test this for a week now, so BEWARE: it is UNTESTED. There is also a "BRANCH" variable in toolchain.eclass, this might be a source of confusion as well. Any feedback is welcome. Regards, Dominik (In reply to comment #10) > Hi, > > as I read all those bugzillas, I never saw a report that's showing emerge > messages of upgrades from x.x.x to y.y.y. > Though there are a lot of claims like "me too, from x.x.x to y.y.y", I never saw > a cut-n-paste of such error messages. The cut-n-paste messages were always of > the form "x.x.x-datestamp" to y.y.y. I can confirm this, never had a single issue upgrading between all those gcc-4.0.x dated snapshots, but upgrading from gcc-4.0.2_pre20050917 to gcc-4.0.2 caused this bug. to also include "pre..." as a valid "minor version" string, not just "$5" as mentioned in comment#10 (though there are even more places where "$5" might have to be substituted, and meanwhile I also saw that there's a "gcc_branch" variable, too, and I still didn't find time to verify that code snippet "in real life"...) awk ' \ { \ num=split( $0, ver, "[-_]" ); \ if (num < 5) { exit 1 }; \ printf( "%s", ver[5] ); \ for (i=6; i<=num; i++) { \ if (ver[i] ~ "^[[:digit:]._]*$") { \ printf( "-%s", ver[i] ) \ } \ else { \ if (ver[i] ~ "^pre[[:digit:]._]*$") { \ printf( "_%s", ver[i] ) \ } \ else { \ i=num \ } \ } \ }; \ print ""; \ exit 0 \ }; \ END {exit 1}' If You want to try this: - backup Your toolchain.eclass, e.g. cp -a /usr/portage/eclass/toolchain.eclass /root/toolchain.eclass.backup - edit toolchain.eclass line ~1964 ff.: vi +/curr_config_ver= toolchain.eclass replace "awk -F - '...'" take care to keep the (closing) right parenthesis from "curr_config_ver=$(" ... ")" at the end of the line, it must follow after the replaced code like this: END {exit 1}' ) and replace that code twice: if has_version ...; then curr_config_ver=$( ... | awk <code here> ) else curr_config_ver=$( ... | awk <code here> ) fi BTW, a note to toolchain maintainers (if they read this:) IMHO it would be easier to use the same char ("-" instead of "_") for the "pre" versioning... should be fixed now |