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

[David Faure]

On Monday 23 February 2004 20:52, Michael Matz wrote:
> Hi,
> 
> On Mon, 23 Feb 2004, David Faure wrote:
> 
> > You can compile _all_ of KDE with --disable-rpath to disable that
> > feature, but it doesn't work if e.g. kdelibs's .la file use rpath,
> > because in that case you'll still get the kde dir in the -L flags, even
> > if you disable rpath for e.g. kdenetwork. I had the same problem
> > recently.
> 
> Also, libtool encodes the install dir of a lib as rpath for depending 
> libs.

Exactly - that's what bit me.

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

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

I don't see how this is correct, since there's no way out once things are compiled.
That's the big problem with the rpath feature...

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.
By simply moving the local ../foo/bar.la before the $(LIB_KBLEH) the
order of the rpaths ended up being the right one.

> > I certainly wish that LD_LIBRARY_PATH could override rpath, but
> > apparently that's not the way ld.so works. Anyone who knows more about
> > this: any other env. var that would override rpath? Or should we file a
> > wishlist with the ld.so developers? :)
> 
> DT_RUNPATH would be searched after LD_LIBRARY_PATH, but unfortunately ld 
> encodes the rpath info with the DT_RPATH tag (which is deprecated and 
> searched before LD_LIBRARY_PATH). 
So that's a bug in ld? If it used the non-deprecated one, LD_LIBRARY_PATH would allow
to override it?

> But linux ld.so supports an  
> --inhibit-rpath BLA:BLUBB argument, which makes it ignore any such tags in 
> the objects BLA and BLUBB (which is not very usable I admit, as you would 
> have to add all objects which have these tags to ignore it for the whole 
> process).
Ouch :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).