2

I will put you in context:

I have 2 third party shared libraries: libA.so and libB.so. My program contains only calls to libA.so symbols. The libA.so internaly needs to call to libB.so. If I readelf LibA.so it has a RunPath pointing to a path from the third party developer that doesn't exsist in my system.

My program builds with cmake. I use find_library(A) and find_libary(B) and then add them to my program executable target with target_link_libraries(my_executable PUBLIC A B)

With this setup the generated executable contains a correct RUNPATH for both libA.so and libB.so. The problem is that when running the executable the libB.so file is not found.

I need to keep the .so files in the place they are. Setting up LD_LIBRARY_PATH env variable or moving to a ldd valid folder is not an option. I have tried these solutions and they work btw.

How could I make the executable to find libB.so in this case.

Thanks in advance.

Iván Valdés
  • 49
  • 5

1 Answers1

1

You can change RPATH with a tool named patchelf:

sudo apt install patchelf
patchelf --set-rpath \$ORIGIN libMyLibrary.so

Note that $ORIGIN here means "search in the folder where this library located". You can also combine values like this: \$ORIGIN:\$ORIGIN/../lib. This is convenient if you want to keep unix-like installation structure (executables in bin, libraries in lib).

Osyotr
  • 784
  • 1
  • 7
  • 20
  • This would work. There is no solution that does not involve patching the third party .so? – Iván Valdés Jan 27 '22 at 07:32
  • @IvánValdés you've already mentioned all of them in your question. I personally don't see a problem here, especially if you use package managers like vcpkg. Just add patching step after downloading prebuilt library and that's it. You could also contact library authors and ask them to fix this, but I assume you wouldn't ask the question in the first place. – Osyotr Jan 28 '22 at 14:13