LD_LIBRARY_PATH not being honoured (Re: Crash on launch with no X error message)

[Michael Matz]

Hi,

On Mon, 23 Feb 2004, David Faure wrote:

> > This is not configurable (and in fact it is correct for most use  
> > cases).
> 
> Is it really? Imagine you have a $KDEDIR, a kmylib.{la,so} in it, and a
> kmyapp linking to kmylib (like the kopete guys, or like I had with
> kdepim's libs and kgpgcertmanager, etc.)
> 
> Then you want to install another version of kmylib+kmyapp in another
> prefix, to test things, say $NEWPREFIX, but using the base kde
> installation for the kde libs.

Like I said, for some usecases it's indeed not what is wanted ;-)  One of 
them is this "one-lib-installed-in-two-dirs-one-of-them-the-system-dir" 
scenario.

> Of course kmylib links to KDE libs (libkdecore etc.), which are only in
> $KDEDIR/lib, so what you said above makes libtool use that dir
> ($KDEDIR/lib) as RPATH when linking kmylib+kmyapp. This means kmyapp
> will NEVER be able to find $NEWPREFIX/lib/libkmylib.so/la as it should,
> $KDEDIR/lib/libkmylib.so being in the RPATH....

The RPATH will also contain $NEWPREFIX/lib, but possibly after the 
$KDEDIR/lib entry.  With LD_LIBRARY_PATH you have a similar problem, only 
that you can solve it manually (by simply insuring that the user sets this 
envvar in the correct order).

> I also found out that both prefixes ended up in the rpath, of course, so
> it was a matter of their order... and that only depends on the order
> libtool reads the .la files, i.e. the order of things in the LIBADD
> line!!! Pretty unintuitive.

With LD_LIBRARY_PATH it's the same.

> By simply moving the local ../foo/bar.la before the $(LIB_KBLEH) the
> order of the rpaths ended up being the right one.

And was bar.la depending on LIB_KBLEH?  In that case bar.la anyway has to 
be listed before it, so this misfeature of libtool even made you fix a 
different bug.  Very useful misfeature then ;-)

Yes, I agree, sometimes this behaviour is not what is wanted.

> So that's a bug in ld? If it used the non-deprecated one,
> LD_LIBRARY_PATH would allow to override it?

Yes.  ld supports the --enable-new-dtags argument which makes it emit 
DT_RPATH and DT_RUNPATH.  DT_RPATH is ignored when DT_RUNPATH is there, so 
if I see correctly when this option is used inside gcc one could use 
LD_LIBRARY_PATH to override this.  Hmm, a good idea of mine ;-)  I'll try 
to change the specs of GCC then.


Ciao,
Michael.