Bad rpath/LD_LIBRARY_PATH settings in kdelibs build scripts?

[Alexander Neundorf]

On Wednesday 05 June 2013, Alex Merry wrote:
> On 04/06/13 23:01, David Faure wrote:
> > Hm, but why doesn't it work then? I see builddir/libkdeqt5staging/src in
> > both the RPATH and the RUNPATH, and one of these has priority over the
> > env var, no? I must be confused about how they work, then.
> 
> https://blog.qt.digia.com/blog/2011/10/28/rpath-and-runpath/ suggests
> that RPATH is only used if RUNPATH is not set.  --enable-new-dtags sets
> both, which (with a modern loader) seems to mean that it behaves as if
> only RUNPATH is set (I guess the RPATH is a backwards-compatibility
> measure).

Yes.
If RUNPATH is set, RPATH is ignored. LD_LIBRARY_PATH has priority over 
RUNPATH, but not over RPATH.
 
> The ideal solution would probably be to set RPATH at build-time and only
> set RUNPATH at install-time, but (from what I've read) it doesn't seem
> possible to patch in the value like that (and we'd have to re-link
> instead).  I may be wrong about that, though.

I do not know.
I would think, as cmake is able to patch in the RPATH/RUNPATH at install time 
without needing to relink, it should be possible to patch in the tag (or how 
it is called) whether the entry is RPATH or RUNPATH too, maybe.

> Failing that, at least having the option to unset --enable-new-dtags may
> be useful for developers (although, of course, overriding runpaths with
> LD_LIBRARY_PATH may *also* be useful to developers).

Actually I still do not understand why RUNPATH is considered so much better 
than RPATH.

Alex