10
Мне сложно понять абсолютный путь, на который ссылается @loader_path.Какой путь разрешает @loader_path?
[email protected]:~$ 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)
Я хочу знать, где система ищет, чтобы найти libz.1.dylib.
С некоторой Mac documentation:
@ loader_path/ Эта переменная заменяется на путь к каталогу, содержащему macho-бинарный файл, который содержит команду загрузки с помощью @loader_path. Таким образом, в каждом двоичном, @loader_path решает другой путь
Я предположил бы, что это означает @loader_path только путь к файлу объекта (zlib.so), но это не похоже, чтобы быть правдой.
Есть ли утилита командной строки, которая разрешит путь @loader_path к фактическому пути, который используется при попытке открыть библиотеку?
Спасибо за подтверждение по адресу @loader_path. В конечном счете, мне нужен полный список библиотек, от которых зависит данный объектный файл, и где система будет искать их. Есть ли простой способ создать этот список? – ChrisB
Ну, объектный файл не зависит от какой-либо библиотеки. Linker устанавливает зависимости, поэтому только целевые двоичные файлы имеют зависимости. И 'otool -L' это способ увидеть их. И вся дополнительная информация, которая может помочь решить эти пути, находится в 'man dyld' (это ссылка, которую вы предоставили) –
cody
Могу ли я спросить, почему это не полезно для автономных библиотек? Я пытаюсь получить библиотеку, собранную для переносимости. Должен ли я использовать что-то еще? Я пришел сюда, посмотрев, что означает '@ loader_path', из https://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac –