On 24-11-2006 16:58:46 +0100, Michael Haubenwallner wrote:
> Hi,
>
> on solaris, I had a problem that my usr/bin/python did not find
> libstdc++.so.6 (as of python-2.4.2).
>
> This really is not a python problem, but more general, because we only
> add "-Wl,-R${EPREFIX}/lib:${EPREFIX}/usr/lib" to LDFLAGS.
> Thing is, libstdc++.so.6 resides in a very gcc-specific directory,
> ${EPREFIX}/usr/lib/gcc/i386-sun-solaris2.10/4.1.1/, and gcc does not add
> an appropriate -R/-rpath linker flag for good reasons.
This is weird, because the Wl,-R{path} thing should be (and on Linux is)
an extra suggestion for the runtime linker where to look. In other
words, it more or less sets LD_LIBRARY_PATH just and only for the
dynamic lib it loaded to find its dependencies. Thereby it should not
throw away the system/default paths. Hence, it feels kind of strange to
me that this happens.
I recently toyed with gcc-apple with more or less the same problem:
libstdc++.6.dylib is normally installed in ${prefix}/lib, but this of
course makes trouble if you want to install multiple compilers. So
instead, I decided, to just like toolchain.eclass move away those libs
into ${prefix}${CHOST}/gcc/${ver}/ and hoped that it would work. It
turned out not to work, as gcc_config (like you wrote below) only copies
over libgcc_s*. However, I found the following flag to gcc's configure
which makes gcc install libgcc_s*, libstdc++* by itself in the location
where we want it. And after compiling aspell (which needs libstdc++) I
could verify that it now points to that location indeed, instead of
rimple /usr/lib.
In toolchain.eclass this flag (--enable-version-specific-runtime-libs)
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.
> In main Gentoo Linux, /etc/ld.so.conf contains a list of that
> gcc-specific directories, which is dynamically updated when changing
> installed gcc versions.
> But we cannot dynamically change runtime path that way, because we don't
> want to use LD_LIBRARY_PATH for other good reasons (fex 'env -i').
yep.
> Now, I've fixed it this way:
>
> My 'gcc-config' also copies 'libstdc++.so.*' to ${EPREFIX}/lib now, as
> it already does for 'libgcc_s.so.*'.
>
> Attached patch is for 'gcc-config-1.3.14-prefix.patch'.
> Don't be confused, it's a patch for a patch-file, just adding 'stdc++'
> to the list of to-be-copied libraries.
I am easy to confuse, don't worry ;)
> Comments welcome.
>
> BTW: python-2.4.4 does not runtime-depend on libstdc++.so any more
> (why?), but it is not just python having this issue. After emerging
> recent system+vim here, sys-libs/groff-1.19.2-r1 and sys-libs/db-4.3.27
> provide binaries and sharedlibs depending on libstdc++.so.6.
What do you think of my piece of proze above?
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
