On Fri, 2006-11-24 at 17:16 +0100, Fabian Groffen wrote:
<snip>
> In toolchain.eclass this flag (--enable-version-specific-runtime-libs)
Ah, did not realize that this isn't used, because it looks like this.
Well, I use this one with my toolsbox' built gcc, but gcc doesn't add
-R/-rpath too here. So I have (because I really need it) LD_LIBRARY_PATH
deeply set into the gcc-specific location.
> isn't used, but maybe we should? The problem of your solution is, that
> with multiple compilers your program might end up with a lib that
> doesn't belong to the compiler that program was compiled with. It will
> probably mostly work (due to the version in it), but it feels kind of
> hairy.
This looks like the same issue main Gentoo Linux had when upgrading from
gcc-3.4 to gcc-4.1, both providing libstdc++.so.6, where initially was
said that no 'emerge -e world' is required, but in the end after some
problems, they suggest doing a complete rebuild.
Have just tried this on my main Gentoo box (current gcc is 4.1.1):
$ g++-3.4.6 xx.cc
$ ldd a.out
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.so.6
(0xb7e0a000)
libm.so.6 => /lib/libm.so.6 (0xb7de6000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcc_s.so.1
(0xb7ddc000)
libc.so.6 => /lib/libc.so.6 (0xb7cc5000)
/lib/ld-linux.so.2 (0xb7efe000)
After switching to gcc-3.4.6 (gcc-config as root) and
sourcing /etc/profile, this came out:
$ ldd a.out
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6
(0xb7e0b000)
libm.so.6 => /lib/libm.so.6 (0xb7de7000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1
(0xb7dde000)
libc.so.6 => /lib/libc.so.6 (0xb7cc7000)
/lib/ld-linux.so.2 (0xb7ef0000)
Thing is, current compiler's libdir is before the others
in /etc/ld.so.conf, resulting in that ones being loaded if version
matches.
This is same as what would be when we copy libstdc++ to prefix/lib.
/haubi/
--
[EMAIL PROTECTED] mailing list
