handling of @rpath?

[dekdevy]

Hey,

I made an executable that includes a library (FMOD just in case you care).. When I run the bundler on my app, it does everything correctly for all the other dylibs that it uses, it also copies all the dylibs (including the fmod.dylib!) into the libs folder, it changes all the entries on my executable correctly to be "libs/xxxx.dylib", however it doesnt change the one for fmod.dylib - it stays "@rpath". The result is that it doesnt run on another machine because the fmod.dylib isnt found. in order to make it work i have to manually use the install_tool to change the @rpath entry to become the same like the other entries, which is terribly annoying. can this be fixed or is there a way to add the rpath entries to be handled by dylib?

[auriamg]

One of the main reasons why dylibbundler never handled rpath is because rpath libraries already are "bundleable", it means the author of that library already handled bundling, and dylibbundler trying working on top of that would be redundent (and in some cases might break some setups that rely on rpath). I don't remember the exact syntax by heart, but you can just add some compiler flag while building your application to tell where to look for rpath libs, that should solve your issue

[ksherlock]

The linker flag is:

 -rpath path
             Add path to the runpath search path list for image being created.  At
             runtime, dyld uses the runpath when searching for dylibs whose load
             path begins with @rpath/.

To pass it via clang, you need to escape it, e.g.:

-Wl,-rpath,@executable_path/../Frameworks

@executable_path is relative to the main executable. @loader_path is relative to a library.

That embeds an LC_RPATH load command into the binary. use otool -l to verify it. e.g.:

Load command 42
      cmd LC_RPATH
  cmdsize 48
     path @executable_path/../Frameworks (offset 12)

[dekdevy]

Sweet!