3

For simplicity, here's an example of what I'm trying to achieve:

CMakeLists.txt:

cmake_minimum_required(VERSION 3.9)
project(example)

add_library(${PROJECT_NAME} SHARED)
target_link_libraries(${PROJECT_NAME} PUBLIC objc)
set_target_properties(${PROJECT_NAME} PROPERTIES LINKER_LANGUAGE CXX)

After building it, I run the following command:
otool -L libexample.dylib which outputs:

libexample.dylib:
    @rpath/libexample.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

Is there anything that could be done through CMake to cause the linking to the objc library to use rpath instead of the full path? @rpath/libobjc.A.dylib instead of /usr/lib/libobjc.A.dylib

Edit:
I've tried the solution for this question, but it doesn't seem to fix my issue. The output of the otool command remains the same.

Edit 2:
The following example still links to the full path and not the rpath:

cmake_minimum_required(VERSION 3.9)
project(example)

set(CMAKE_MACOSX_RPATH TRUE)
set(CMAKE_SKIP_BUILD_RPATH  FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_NAME_DIR "@rpath/")

add_library(${PROJECT_NAME} SHARED)

set_target_properties(${PROJECT_NAME} PROPERTIES
        LINKER_LANGUAGE CXX
        LINK_FLAGS "-Wl,-rpath,./"
        MACOSX_RPATH TRUE
        SKIP_BUILD_RPATH FALSE
        BUILD_WITH_INSTALL_RPATH TRUE
        INSTALL_RPATH_USE_LINK_PATH TRUE
        INSTALL_NAME_DIR "@rpath/")

target_link_libraries(${PROJECT_NAME} PUBLIC objc)

Edit 3:

With further investigation, I've come to the conclusion that this wouldn't be possible without using install_name_tool -change. From this issue, it appears that for any external libraries (outside the build tree) the resulting linking path will be whatever the id of the library is (use: otool -D /usr/lib/libobjc.A.dylib to find the id of the lib).

martin
  • 1,007
  • 2
  • 16
  • 32
  • See this answer: https://stackoverflow.com/a/43333118/499581 – l'L'l May 01 '18 at 18:39
  • Tried the solution in that question, but when I inspect the dylib, the result is the same. As a workaround, I could use `install_name_tool -change`, but it'd be much cleaner if CMake had a way of doing this in place. – martin May 01 '18 at 20:19
  • I totally agree that it would be cleaner than using `install_name_tool` each time. Which methods did you try on the linked question/answer? There seem to be multiple methods outlined. From my understanding `SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)` would be the main override for excluding the full pathname. – l'L'l May 01 '18 at 20:22
  • I tried quite a few combinations from that answer, and also from this link: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling but still no luck. I suppose something to note is that I'm looking for this to work after the build step (not install). – martin May 01 '18 at 20:40
  • Since you are wanting this for the build stage then `SET(CMAKE_SKIP_BUILD_RPATH FALSE) # when building, don't use the install RPATH already # (but later on when installing)` and `SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)` is what you would use. You can also try `INSTALL_NAME_DIR` and `MACOSX_RPATH`... – l'L'l May 01 '18 at 20:44
  • The key section in the documentation I believe you'll want to look at is titled **Default RPATH settings**. – l'L'l May 01 '18 at 20:50
  • Yes, I agree that the documentation addresses this issue, but the fix outlined there doesn't seem to work from my experience with it. I've amended the question with an additional non-working example. – martin May 01 '18 at 21:05
  • 1
    You have `CMAKE_BUILD_WITH_INSTALL_RPATH` set to `TRUE` when it should be `FALSE`; same with `CMAKE_INSTALL_RPATH_USE_LINK_PATH`. – l'L'l May 01 '18 at 21:59
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/170185/discussion-between-vejmartin-and-lll). – martin May 01 '18 at 22:07

0 Answers0