Support RUNPATH as well as RPATH

[citibeth]

Some users prefer RUNPATH instead of RPATH. Make Spack support either style of adding paths to binaries.

[citibeth]

@hegner said:

I fully agree to LD_LIBRARY_PATH being evil (or let’s say too fragile). Now the thing about RPATH is that it doesn’t allow any overriding of libraries by locally built ones. Sometimes you just want to load a different library providing the same symbols. And only if it is the same lib, with a bug fix you want to test before complete deployment… there are plenty of these cases. Thus RUNPATH seems the better option to me.

[tgamblin]

This is doable but there are linking ramifications. You may think that RUNPATH is the same as RPATH, but with an optional override from LD_LIBRARY_PATH. However, the search semantics for them are actually different. Here is the lookup order, thanks to Qt:

Unless loading object has RUNPATH:
    RPATH of the loading object,
        then the RPATH of its loader (unless it has a RUNPATH), ...,
        until the end of the chain, which is either the executable
        or an object loaded by dlopen
    Unless executable has RUNPATH:
        RPATH of the executable
LD_LIBRARY_PATH
RUNPATH of the loading object
ld.so.cache
default dirs

Note that RPATH will search its parent objects' RPATHs, while RUNPATH does not search parents' RUNPATHs. The situations where this matters are complicated (see the Qt blog above), and I haven't worked out how Spack should set RUNPATHs. Right now, we actually set more RPATHs than we need (we set RPATHs for the whole DAG, and could probably get away with just immediate deps).

For RUNPATH, I suspect that things work in most cases, but in certain cases like the one in the link above, I am not sure that we can always generate something that will run correctly without also relying on LD_LIBRARY_PATH. This seems bad to me.

[hegner]

For the Qt case I believe setting more RUNPATHs thar required would be enough. In the end that's contained within a single package with locations well known at compile time.
In general, however, neither RPATH nor RUNPATH are sufficient for plugin systems. The nice thing about plugins is that one can extend a project A by plugins in another project B. And A and its plugin loader obviously don't know about B at compile time yet, thus no chance of having proper RPATH or RUNPATH. So environment variables are needed anyhow.

[citibeth]

I would suggest that we just make a simple Spack configuration parameter to
use RUNPATH instead of RPATH, and keep it on an experimental branch. This
will provide @hegner the basic feature needed to try things out, and see if
RUNPATH works in a meaningful way in real-life situations. We can
re-evaluate later.

-- Elizabeth

On Sat, Mar 26, 2016 at 3:15 AM, hegner notifications@github.com wrote:

For the Qt case I believe setting more RUNPATHs thar required would be
enough. In the end that's contained within a single package with locations
well known at compile time.
In general, however, neither RPATH nor RUNPATH are sufficient for plugin
systems. The nice thing about plugins is that one can extend a project A by
plugins in another project B. And A and its plugin loader obviously don't
know about B at compile time yet, thus no chance of having proper RPATH
or RUNPATH. So environment variables are needed anyhow.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#639 (comment)