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

[David Faure]

On Tuesday 24 February 2004 15:42, Michael Matz wrote:
> 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.

Yes, that is another case where rpath makes it very difficult currently.

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

> > 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.
Well, everyone knows order matters there, and it's easy to fix.
Up to a few days ago I didn't know that order mattered in Makefile.ams...

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

This is really new to me. I thought the order of the libs in LIBADD/LIBADD 
only mattered for static builds (which don't work in KDE anyway for many reasons).

So what's the general rule? When A depends on B, put A before B?
I need to add that to the Makefile.am howto...
Martijn: check your Makefile.ams, maybe the solution to the [lib]kopete problem
lies there as well.

> 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.
Honestly I don't understand a word of that paragraph, but it sounds like you're
going to fix something, so it sounds good :-)

Thanks.

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions