22

I'm having a hard time understanding the absolute path that a @loader_path within a file refers to.

user@local:~$ otool -L zlib.so 
zlib.so:
    @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

I want to know where the system looks to find libz.1.dylib.

From some Mac documentation:

@loader_path/ This variable is replaced with the path to the directory containing the mach-o binary which contains the load command using @loader_path. Thus, in every binary, @loader_path resolves to a different path

I would have guessed this means that @loader_path is just the path to the object file (zlib.so), but that doesn't seem to be true.

Is there any command line utility that will resolve @loader_path to the actual path that is used when attempting to open a library?

ChrisB
  • 4,628
  • 7
  • 29
  • 41

2 Answers2

6

Your guess is right: in this case @loader_path is the path to the directory, containing zlib.so. But there probably will be problems with using this lib. Where did you get that lib? If you are building it by yourself, see this question for some info.
The @loader_path is useful for the frameworks and plugins, but not for the standalone libraries.

Community
  • 1
  • 1
cody
  • 3,233
  • 1
  • 22
  • 25
  • Thanks for the confirmation on @loader_path. Ultimately, I want the complete list of libraries that a given object file depends upon, and where the system is going to look for them. Is there a simple way to generate that list? – ChrisB May 30 '13 at 20:27
  • Well, object file doesn't depend on any library. Linker sets dependencies, so only target binary has dependencies. And `otool -L ` is the way to see them. And all additional info which can help to resolve those paths is in `man dyld` (that is the link you've provided) – cody May 31 '13 at 06:14
  • May I ask why this is not useful for standalone libraries? I am trying to get a library compiled to be portable. Should I use something else? I got here by looking up what `@loader_path` means from https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac – P.R. Nov 20 '14 at 19:34
  • 1
    As far as I remember because `@loader_path` is about relative stuff. In plug-ins you have few binaries, which can be relative to each other, and if you will link them using `@loader_path`, you can move plug-in itself around the file system safely. But in case of standalone library why do you need that path? Take a look at section about `@loader_path` in `man dyld` for info – cody Nov 24 '14 at 19:52
  • @cody Thanks for the higher level answer that goes with the question, as well as the hint that man dyld documents it!! – clearlight Aug 18 '18 at 14:10
  • Good read to get basic understanding of `@executable_path` , `@loader_path` and `@rpath` https://wincent.com/wiki/%40executable_path%2C_%40load_path_and_%40rpath – technerd Sep 11 '18 at 05:34
0

@loader path will be replaced by the current binary path

install_name_tool -add_rpath "@loader_path/Gstreamer/Versions/Current/lib binfile(binary to which you want to link the dylibs)
Usama
  • 159
  • 1
  • 13