Какой путь разрешает @loader_path?

Мне трудно понять абсолютный путь, на который ссылается @loader_path в файле.

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)

Я хочу знать, где система ищет libz.1.dylib.

Из некоторой документации Mac :

@loader_path/ Эта переменная заменяется путем к каталогу, содержащему двоичный файл mach-o, который содержит команду загрузки с использованием @loader_path. Таким образом, в каждом двоичном файле @loader_path разрешается в другой путь.

Я бы предположил, что это означает, что @loader_path — это просто путь к объектному файлу (zlib.so), но это не похоже на правду.

Существует ли какая-либо утилита командной строки, которая преобразует @loader_path в фактический путь, который используется при попытке открыть библиотеку?


macos shared-libraries dyld mach-o otool
person ChrisB    schedule 30.05.2013    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Ваше предположение верно: в данном случае @loader_path — это путь к каталогу, содержащему zlib.so. Но, вероятно, будут проблемы с использованием этой библиотеки. Где ты взял эту либу? Если вы создаете его самостоятельно, см. этот вопрос для информации.
@loader_path полезен для фреймворков и плагинов, но не для автономных библиотек.

person cody    schedule 30.05.2013
comment
Спасибо за подтверждение на @loader_path. В конечном счете, мне нужен полный список библиотек, от которых зависит данный объектный файл, и где система будет их искать. Есть ли простой способ создать этот список? - person ChrisB; 31.05.2013
comment
Ну, объектный файл не зависит ни от какой библиотеки. Компоновщик устанавливает зависимости, поэтому только целевой двоичный файл имеет зависимости. И otool -L <binary> это способ увидеть их. И вся дополнительная информация, которая может помочь разрешить эти пути, находится в man dyld (это ссылка, которую вы предоставили) - person cody; 31.05.2013
comment
Могу я спросить, почему это не полезно для автономных библиотек? Я пытаюсь собрать библиотеку, скомпилированную для переносимости. Должен ли я использовать что-то еще? Я попал сюда, посмотрев, что означает @loader_path, на blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac< /а> - person P.R.; 20.11.2014
comment
Насколько я помню, потому что @loader_path относится к относительным вещам. В плагинах у вас есть несколько двоичных файлов, которые могут быть связаны друг с другом, и если вы слинкуете их с помощью @loader_path, вы можете безопасно перемещать сам плагин по файловой системе. Но в случае с отдельной библиотекой, зачем вам этот путь? Посмотрите раздел о @loader_path в man dyld для получения информации - person cody; 24.11.2014
comment
@cody Спасибо за ответ более высокого уровня, который сопровождает вопрос, а также за намек на то, что man dyld документирует это !! - person clearlight; 18.08.2018
comment
Полезно прочитать, чтобы получить общее представление о @executable_path , @loader_path и @rpath wincent.com/wiki/< /а> - person technerd; 11.09.2018