* Charles Wilson wrote on Sun, Aug 01, 2010 at 02:10:36PM CEST:
> On 8/1/2010 6:46 AM, Ralf Wildenhues wrote:
> > Because that allows it to set run paths to the compiler libs?
> > (I don't know either.)
>
> Hmm. If so, what use case does that capability have? You want to install
> an application compiled with a non-standard compiler, but whose compiler
> runtime lib has the same name as the standard one, so only the standard
> one is "registered" in ld.so.conf?
>
> It seems that this is such an odd use case that it should be handled
> separately (e.g. via a libtool option that the user can pass via LDFLAGS
> (-use-syslib-rpath), rather than built in to the way libtool operates
> normally).
Could be.
I thought of another reason: likely, for a while the compiler drivers
simply couldn't create shared libraries correctly. Seems very weird,
yes, but look at some Fortran compilers where that's still the case
today.
> > It precedes my time anyway. We should clean it up and disable it for
> > the compilers and systems where we know that it works. That is a
> > separate issue, and hopefully we can keep it separate, but IIUC it
> > influences this patch series and how much work it is to get right.
> > Not sure which strategy would be easiest for you.
>
> I agree it is a separate issue. Paolo has already found the reason that
> his original patch broke the postdep detection, and fixed it, so it's
> really not an immediate issue with respect to sysroot.
>
> At some point it will be necessary to take the plunge, as various g++
> (and even, gcc) flags like -shared-{libgcc|libstdc++|libfortran?} (or
> -static-*) can affect both postdep detection and final link behavior.
>
> But it'll be a big scary change, no doubt.
Agreed on all counts. Good thing we can keep the issues separate.
Cheers,
Ralf
