1

I want to build an executable foobar on Linux, that depends on shared libraries such as libfoobar.so. So I do

gcc foobar.o -Xlinker -rpath relative path from executable to library-lfoobar -o foobar

I have to provide the path to the library so that the linker does not complain, even though the library is not needed at link time.

Then the executable and libraries get installed to system directories (which are unrelated to the initial locations and to each other).

After that, I can't run it, because the path to the library, used to build is no longer valid, and the library is not found.

What is the best way to setup linker options so that they work both at link time and at runtime?

I cannot use absolute paths, they are a bad idea in general to use during build, and also not possible during runtime, as different users will have different installation roots. Only the relative paths at build time and runtime, are guaranteed to be always the same.

Mark Galeck
  • 6,155
  • 1
  • 28
  • 55
  • Have you tried creating a symlink to the .so file so the relative path to the symlink during runtime is the same as during linking? – Karol Szustakowski Jun 02 '19 at 14:28
  • @KarolSzustakowski I have not, and I will, thank you. But my question is more like, what is the _canonical_ way to it, rather than, how to improvise a hack. – Mark Galeck Jun 02 '19 at 14:43
  • 1
    You should probably try ORIGIN-based solutions. But be warned - they are tricky because of shell and makefile substitutions. `$ORIGIN/../lib` goes in, and `RIGIN/../lib` comes out when inspecting with `objdump -p`. Also see [A description of RPATH $ORIGIN LD_LIBRARY_PATH and portable linux binaries](https://enchildfone.wordpress.com/2010/03/23/a-description-of-rpath-origin-ld_library_path-and-portable-linux-binaries/). – jww Jun 03 '19 at 10:13

0 Answers0