On Tue, 2006-11-28 at 14:13 +0100, Fabian Groffen wrote:
> 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)
portage does not create an $EPREFIX/etc/ld.so.conf here ?
Where do the $EPREFIX/etc/env.d/ LDPATH values go to instead ?
<snip>
> > 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.
Time is not the only issue, it is the users nature to simply not
understand _why_ this is required, especially if it needs to be done
manually.
<snip>
>
> > 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.
What are the gcc libs different than libs from any other package, except
that they are more basic ? What about glibc (on native Gentoo) ?
For me, glibc and gcc are somehow on the same very basic level...
IMO gcc is one of that rare packages where 'soname' is used correctly.
To me, it seems that gcc devs try harder than other package's devs to
ensure that a newer lib is compatible to an older one with same
'soname'.
Maybe gcc-config should ensure the lib{gcc_s,stdc++,...}.so* symlinks
point to the one from most recent available gcc in EPREFIX/lib,
regardless of which gcc is actually selected ?
>
> 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.
Yes. But an old gcc version really should be removed if no more packages
are built with it, earliest after a successful 'emerge -e world'.
And when gcc-config keeps most recent version in /lib,
> That might be the rationale behind the gcc-config hack...
Maybe. Of course it makes sense.
/haubi/
--
[EMAIL PROTECTED] mailing list
