4

I'm trying to link a cmake build with two shared libraries, linking occurs but RPATH is pointing to an absolute path of one of the two libraries while readelf output is incorrect for the other.

What I did is the following:

add_library(foo SHARED IMPORTED)
set_target_properties(foo 
  PROPERTIES IMPORTED_LOCATION ${LIBS_DIRECTORY}/foo/libfoo.so
)

add_library(bar SHARED IMPORTED)
set_target_properties(bar
  PROPERTIES IMPORTED_LOCATION ${LIBS_DIRECTORY}/foo/libbar.so
)

target_link_libraries(myprogram foo bar)

This works and linking occurs but readelf prints the following:

0x0000000000000001 (NEEDED)             Shared library: [../../../libs/foo/libfoo.so]
0x0000000000000001 (NEEDED)             Shared library: [libbar.so]
0x000000000000000f (RPATH)              Library rpath: [/home/user/test/trunk/libs/foo:/home/user/test/trunk/libs/bar]

So basically one of the two libs (but just one, and it makes no sense) has an absolute path while rpath contains both the full paths (which is not what I want to do, since I want to ship the executable with the two libraries in the same folder of the exectuable (or a subfolder at most).

Am I missing something trivial?

Jack
  • 131,802
  • 30
  • 241
  • 343
  • CMake [rewrites the RPATH](https://cmake.org/Wiki/CMake_RPATH_handling#CMake_and_the_RPATH) when you call `make install` to become portable. Did you do this? – ComicSansMS May 11 '16 at 14:08
  • @ComicSansMS: I don't have an install target at all since I'm using cmake only as a build tool, not as a redistribution script (source code is closed), so my main interest is to be able to compile it and make it work with shared libraries shipped together with the executable, nothing more. – Jack May 11 '16 at 14:11
  • You probably will need to add an install step then. IIRC the rpath that is generated on build is specific to the build tree and is prone to breaking if you start copying stuff around. Installing should typically clean this up (and might even work without changing any of the rpath-related default settings). Unfortunately, this is a fiddly issue and I don't touch this part of CMake too often, so my knowledge here is a bit rusty. – ComicSansMS May 11 '16 at 14:16
  • Turns out you don't need an install step. By setting the [`CMAKE_BUILD_WITH_INSTALL_RPATH`](https://cmake.org/cmake/help/v3.5/variable/CMAKE_BUILD_WITH_INSTALL_RPATH.html) variable to true, you will get the cleaned-up version in the build tree. – ComicSansMS May 11 '16 at 14:29
  • @ComicSansMS: that settings fixes the exported `RPATH` indeed, but foo.so is still linked with its full path (not like bar.so) even if they have the same commands in the `CMakeLists.txt`, which seems weird, I'll try to investigate the issue further but I'm not so practical with CMake unfortunately. – Jack May 11 '16 at 14:58
  • @Antonio: because I changed the names manually to focus on the problem. Actually I've been able to use `set(CMAKE_INSTALL_RPATH "$ORIGIN/lib")` so that now `libbar.so` is correctly found by `ldd` when placed in lib subdirectory of where the executable is but `libfoo.so` is still searched through a relative path to where I invoke `cmake` and `make` but I can't figure why. – Jack May 11 '16 at 15:43
  • Difficult to see what could be the cause of the problem. It might have something to do with the way those libraries are built, or with their own dependencies. What happens if you switch order? – Antonio May 11 '16 at 15:49
  • 2
    @Antonio: I'm randomly testing properties and it looks like `IMPORTED_NO_SONAME TRUE` removes the absolute path but I've no idea why it, I'm really groping around. – Jack May 11 '16 at 15:51
  • @Jack Maybe a bogus duplicate of one of the libraries laying around? – Antonio May 11 '16 at 15:52

0 Answers0