0

I have a CMake project for macOS which generates an executable in an app bundle and has a few dylibs as dependencies. However, I've noticed that some dylibs come with a shared library identification name that's not convenient, and require calling install_name_tool in a postbuild step to fix it. Here's an example of how these dylibs are being referred in the App Bundle's executable:

(...)
Load command 27
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/libFoo.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 0.0.0
compatibility version 0.0.0
Load command 28
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name libBar.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 0.0.0
compatibility version 0.0.0
Load command 29
          cmd LC_LOAD_DYLIB
      cmdsize 40
         name libBaz.dylib (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0
(...)

As I'm generating a macOS Application Bundle I'd prefer if the executable refers to each of these libraries as @executable_path/../Frameworks/libFoo.dylib.

Does anyone know if CMake offers any way to specify these without having to calling install_name_tool in a ad-hoc postbuild target?

RAM
  • 2,257
  • 2
  • 19
  • 41
  • Looks like you are searching how to set RPATH via CMake. There is nice wiki about this topic: https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling. – Tsyvarev Oct 07 '22 at 08:16
  • Using `@rpath/libFoo.dylib` as the install name and a rpath search path of `@loader_path/../Frameworks` is really the best and most flexible choice. Hard-coding the install name as `@executable_path/../Frameworks/libFoo.dylib` means the library can only ever be loaded by an executable (in other words, your other libraries could not link to it). See my post here for more info: https://stackoverflow.com/a/12522096/277952 – NSGod Oct 08 '22 at 17:36

0 Answers0