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?
@executable_path Application location: /Applications/Foo. app. Executable path: /Applications/Foo. app/Contents/MacOS.
executable_path is the parameter through which users can pass the absolute path of the GeckoDriver binary overriding the system path of GeckoDriver binary to be used for Firefox 47.0.
@rpath stands for Runpath Search Path. In the Xcode, it's set with LD_RUNPATH_SEARCH_PATH setting. In ld command tool it's set with -rpath parameter when linking. So it's a search path for the linker. Runtime Search Path instructs the dynamic linker to search a list of paths in order, to locate the dynamic library.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With