On 28-11-2006 14:00:44 +0100, Michael Haubenwallner wrote:
[snipping]
> Maybe we could have the ld-wrapper to read rpath values from
> $EPREFIX/etc/ld.so.conf ?
What about systems that don't use ld.so.conf (i.e. Darwin)
> But then, if sys-libs/libstdc++-v3 replaces gcc, it is required to
> provide libstdc++.so.X in exact the same location.
> Does it do so ?
[snip]
> As you can see, gcc's libstdc++.so.6 is not built with that ld-wrapper
> yet, resulting in having two different libgcc_s.so.1 in the runtime.
> Here, just rebuilding gcc might help, but what if gcc is upgraded, built
> with an older gcc ?
>
> If done so, the previous' gcc path becomes built into the new's
> libstdc++.so.6, resulting the new one depending on the old's
> libgcc_s.so.1, because the old's path is in etc/ld.so.conf.
> Thus, we might have to enforce this steps for upgrading gcc:
> 1) build the new gcc
> 2) activate it by using gcc-config
> 3) rebuild the new gcc with itself
Which for some platforms is definitely unacceptable... as it takes long
to compile the compiler. Besides that, I don't like it either.
> Additionally, possibly having different versions of one sharedlib in one
> process really is more bad than using them from another gcc-version as
> the package was built with. Let the 'soname' ensure that they are
> sufficient. This is true both for libgcc_s and libstdc++.
>
> Or, gcc-config must not copy gcc-libs into EPREFIX/lib.
> But this is unintentional according to comments in gcc-config...
> And the gcc-rebuild with itself keeps being necessary.
I had a chat with Mike Frysinger (vapier) about it. It's not clear why
movelibs is done, but probably because it works better than
--enable-version-specific-libs. I still would like to try the latter
one, as I'd prefer applications to link against the version specific
library instead of to ${EPREFIX}/usr/lib
> Reflecting all that, I become more being for copying libstdc++ into
> EPREFIX/lib in addition to libgcc_s, and let SONAME do its work.
... and libgcj and and and... If feels to fugly to do that. gcc-config
only copies libgcc_s because of backwards compatibility if I got it
right, for apps that were linked against libgcc_s in that place which
will break if you remove it. I'd like no application to ever link
against a gcc lib in usr/lib.
But what if you'd upgrade and remove the old compiler and the lib
disappears? I think it's reasonable to require to reemerge stuff then
in prefix. I can imagine in the base system you're pretty ***** up if
your coreutils link to libgcc_s and you just uninstalled those libs.
That might be the rationale behind the gcc-config hack...
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
