1

This is a follow-up question to this one.

I understand that using $ORIGIN in the -rpath option generates a dynamic absolute path that will always point to the specified location - no matter from where I use the library.

What's confusing me, is the following: I use this library to generate a shared binary and I set (again) the -Wl,-rpath option using $ORIGIN to enable the binary to always find its library. Now the original $ORIGIN value of the library is not available anymore or wrong because it seems to be overwritten by the new one.

Somehow this is understandable since I am now generating a new shared object - the binary - that has its own $ORIGIN. A way around this, would be to provide the binary's -rpath with both locations, the one to the library and the one the library itself needs. In my opinion this makes -rpath almost useless, because I can't just link to the library and specify its location I also need to specify the library's dependency location.

My question: Is there a way to specify hierarchical -rpath values using $ORIGIN? I would like to avoid absolute paths, which would obviously fix my issue.

mattmilten
  • 6,242
  • 3
  • 35
  • 65
  • Here's nice explanation of the problem: http://www.kaizou.org/2015/01/linux-libraries/ – mattmilten Jul 04 '16 at 15:42
  • 1
    It is possible to set an `rpath` inside the library, e.g. if you have App A depending on lib B which depends on lib C, you can `patchelf --set-rpath '$ORIGIN/.' libB.so` to make it look for `libC.so` in the same directory as `libB.so`, regardless of where that is or if it is linked into A explicitly. Does that help? – John Zwinck Sep 06 '16 at 08:56

0 Answers0