Consider the following: me@colinux ~/projects $ ldd /usr/bin/mtn linux-gate.so.1 => (0xffffe000) libboost_regex.so.1.33.1 => /usr/lib/libboost_regex.so.1.33.1 (0xb7ef5000) libboost_date_time.so.1.33.1 => /usr/lib/libboost_date_time.so.1.33.1 (0xb7ee6000) libboost_filesystem.so.1.33.1 => /usr/lib/libboost_filesystem.so.1.33.1 (0xb7ed5000) libz.so.1 => /lib/libz.so.1 (0xb7ebf000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6 (0xb7de5000) libm.so.6 => /lib/libm.so.6 (0xb7dc1000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1 (0xb7db7000) libc.so.6 => /lib/libc.so.6 (0xb7c96000) /lib/ld-linux.so.2 (0xb7f8f000) Now, occationally I need to flip to gcc 3.4.x (colinux requires it to compile). If i do that, the two 4.1.1 libs gets flipped to their 3.4.x versions, which mtn (monotone) doesn't like. How can it be desirable to have dynamically linked apps change their linking, just because the system compiler changes (presumable for the purpose of compiling new applications). Either I've made an error somewhere, or this is a bug. /Anders Reproducible: Always
Fix colinux; absolutely nothing we could do here. http://www.gentoo.org/doc/en/gcc-upgrading.xml
While fixing colinux is desirable, it still begs the question if its supposed to be safe to use gcc-config to compile/install a few apps using another gcc version. My reading of the current situation is that it's unsafe to have applications, compiled with different gcc versions, installed at the same time. Is that by design? If so, one wonder what use gcc-config should serve...
this is a bug/feature in gcc-config, it has nothing to do with colinux or anything else per se. i ran into it myself last year and talked to solar about it, here's the relevant irc log: [14:56] <p> ran into a new issue today w/ gcc/libstdc [14:56] <p> imagine you have gcc 3.4 and 4.1 installed [14:57] <p> their libstdc has the same soname *but* the latter provides extra versioned symbols for the c++ ABI [14:57] <p> readelf -d /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 |grep SONA 0x0000000e (SONAME) Library soname: [libstdc++.so.6] [14:57] <p> readelf -d /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8 |grep SONA [14:57] <p> 0x0000000e (SONAME) Library soname: [libstdc++.so.6] [14:59] <p> strings /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 |grep ABI [14:59] <p> CXXABI_1.3 [14:59] <p> strings /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6.0.8 |grep ABI [14:59] <p> CXXABI_1.3 [14:59] <p> CXXABI_1.3.1 [15:00] <p> now, imagine you switch to 4.1 then compile a c++ app, such as eix [15:00] <p> it will link against versioned symbols, in this case CXXABI_1.3.1 [15:00] <p> so far so good, it works because the ld.so.conf search paths have 4.1 before 3.4 [15:01] <p> (due to the soname match, 4.1 takes precedence) [15:01] <p> now you switch to the 3.4 gcc profile [15:01] <p> (just switch, nothing recompiled/etc at all) [15:01] <p> suddenly, all these c++ apps stop working [15:02] <p> because env-update will put the 3.4 path before the 4.1 one [15:02] <p> so ld.so will match the libstdc from 3.4 which doesn't have the 1.3.1 ABI symbols [15:03] <p> and the reason for env-update switching the order is that gcc-update creates the LDPATH line in /etc/env.d/05gcc based on the current profile and only then does it append the other versions [15:04] <p> so what can be done to fix this easily? for now i manually edited 05gcc and put 4.1 back at the head, but that's not exactly stable as each time i run gcc-config i'll have to think of this [15:05] <p> the one symbol that triggers this whole breakage is: [15:05] <p> readelf -s /usr/bin/eix|grep 1.3.1 [15:05] <p> 37: 00000000 11 FUNC GLOBAL DEFAULT UND __cxa_get_exception_ptr@CXXABI_1.3.1 (6) [15:06] <p> i don't know if that was an intentional change (or more like, breakage) from the gcc people [15:06] <p> but it's a bad idea to do this w/o changing the soname as well [15:08] <p> (that's the only symbol w/ that version btw in libstdc)
reopening...
(In reply to comment #4) > reopening... Hmm, and what kind of solution exactly do you expect here from gcc-config? The ABI is not compatible, end of story.
to re-assign. The issue is due to a C++ ABI change (1.3 to 1.3.1), with no change to the libstdc++ soname version (which remains 6). Normal (well, non-Gentoo) systems don't have the compiler library directories in ld.so.conf - since normal systems don't necessarily have the compiler installed. I think we consider installing the gcc libraries into /usr/lib (i.e. duplicate or symlink them), i.e. /usr/lib/libstdc++.so.6.0.3 /usr/lib/libstdc++.so.6.0.8 /usr/lib/libstdc++.so.6 -> /usr/lib/libstdc++.so.6.0.8 /usr/lib/libstdc++.so -> /usr/lib/libstdc++.so.6 or perhaps /usr/lib/libstdc++.so.6.0.3 -> /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6.0.3 /usr/lib/libstdc++.so.6.0.8 -> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6.0.8 /usr/lib/libstdc++.so.6 -> /usr/lib/libstdc++.so.6.0.8 /usr/lib/libstdc++.so -> /usr/lib/libstdc++.so.6 and remove the compiler library directories from ld.so.conf.
ive been planning on fixing this for sometime, i just havent gotten around to it since it generally isnt a critical issue ... use the -E option rather than switching profiles
(In reply to comment #5) > Hmm, and what kind of solution exactly do you expect here from gcc-config? The > ABI is not compatible, end of story. it's not 'not compatible', that's the thing ;-). gcc libs (at least with the same soname) are supposed to be backwards compatible, that is, gcc 4.1.x provides all the (versioned) symbols that 3.4.x did, therefore apps linking against 3.4.x libstdc++ will continue to run with a newer libstdc++. what we do with gcc-config however is the opposite, we go back in time when we switch to an older gcc profile and still expect that potentially newly introduced symbols (versioned or not) will somehow magically resolve in the older libs - such a guarantee has of course never been given by anyone. therefore the correct solution IMHO is to change gcc-config to keep the gcc version based LDPATH element order instead of pushing the currently selected one in front. something like this: --- /usr/bin/gcc-config.old 2007-04-15 15:05:56.000000000 +0200 +++ /usr/bin/gcc-config 2007-04-15 15:32:25.000000000 +0200 @@ -69,12 +69,12 @@ RM=$(find_path rm) MV=$(find_path mv) LN=$(find_path ln) + LS=$(find_path ls) CAT=$(find_path cat) ENV=$(find_path env) SED=$(find_path sed) AWK=$(find_path gawk) GREP=$(find_path grep) - FIND=$(find_path find) CHMOD=$(find_path chmod) TOUCH=$(find_path touch) PYTHON=$(find_path python) @@ -208,8 +208,7 @@ # compilers for default CHOST will be used to compile stuff, # and thus we want all their lib paths in /etc/ld.so.conf ... get_real_chost - GCC_PROFILES=$(${FIND} "${GCC_ENV_D}" -maxdepth 1 -name "${REAL_CHOST}-*" -a ! -name "${CC_COMP}") - GCC_PROFILES="${GCC_ENV_D}/${CC_COMP} ${GCC_PROFILES}" + GCC_PROFILES=$(${LS} -r1 ${GCC_ENV_D}/${REAL_CHOST}-*) # Extract all LDPATH's for our CHOST MY_LDPATH="" spanky: how would gcc-config -E help?
that solution is still incomplete ... you missed libgcc and such
(In reply to comment #9) > that solution is still incomplete ... you missed libgcc and such uhm, care to elaborate? what breaks with preserving the version order in LDPATH?
look at the code that copies libgcc from the selected gcc version into /lib
(In reply to comment #11) > look at the code that copies libgcc from the selected gcc version into /lib uhm, but that's based on the LDPATHs coming from GCC_SPECS which is now correctly ordered, so the libgcc chosen will be that of the head of the list (i.e., the highest installed gcc version), not the currently selected profile... or is that wrong somehow?
maybe !
implemented your idea with gcc-config-1.4.0, cheers
Hmm, gcc-config-1.4.0 *still* places LDPATH of the default compiler to the top of the list, unlike suggested in comment 8. SpanKY, is this deliberate, or you just forgot to remove the 'GCC_PROFILES="${GCC_ENV_D}/${CC_COMP} ${GCC_PROFILES}"' line? PaX Team does suggest to remove it, see comment 8. I am asking because upgrading to gcc-config-1.4.0 (obviously!) did not help to resolve the problem described in bug 182554.
*** Bug 199901 has been marked as a duplicate of this bug. ***
Is it possible to have per package gcc profiles? Similar to how individual users can set java using 'java-config -s'. Or perhaps have separate system profile/build profile/user profile?
