Re: using ld for linking non-C code

[Charles Wilson]

On 8/1/2010 6:46 AM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Mon, Jul 26, 2010 at 01:57:57PM CEST:
>> As an aside, WHY is it that libtool tries to figure out what the language 
>> driver
>> does, and use ld directly, rather than just trust the language driver and 
>> use it
>> to link instead?  It seems that the current libtool behavior causes a lot of
>> problems because it is quite fragile...
> 
> Because for a long time, the drivers were broken? (I don't know.)

Could be.

> 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).

> 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.

--
Chuck