Как правильно установить пути запуска, пути поиска и имена установки? - PullRequest
Новая
       50

Как правильно установить пути запуска, пути поиска и имена установки?

12 голосов
/ 21 марта 2012

У меня есть коллекция проектов, которые я собираю как динамические библиотеки.Каждый из этих .dylibs зависит от других различных .dylibs, которые я хотел бы поместить в различные другие каталоги (например, некоторые на пути к исполняемому файлу, некоторые на пути к загрузчику, некоторые на фиксированный путь).

Когда язапустить otool -L в скомпилированных библиотеках, я получаю список путей к этим зависимостям, но я знаю, как эти пути устанавливаются / определяются.Они почти кажутся псевдослучайными.Я часами возился с «Настройки сборки» в XCode, чтобы попытаться изменить эти пути (w / @rpath, @executable_path, @loader_path и т. Д.), Но я не могу ничего изменить (как проверено при запуске otool -L).Я даже не совсем уверен, куда добавить эти флаги, и не совсем понимаю разницу между следующими или как их правильно использовать:

Связывание - «Имя установки динамической библиотеки»
Связывание - »Пути поиска пути выполнения "
Связывание -" Другие флаги связи "
Пути поиска -" Пути поиска в библиотеке "

Когда я запускаю install_name_tool -change в различных библиотеках, я могу успешно изменить прогонпути поиска путей (опять же, как проверено, выполнив otool -L для подтверждения).

Я использую Xcode 4.2, и я очень близок к тому, чтобы отказаться и просто использовать сценарий после сборки, который запускает install_tool_name, чтобы сделатьперемены.Но это хакерское исправление, и я предпочел бы этого не делать.

Где я могу посмотреть, как устанавливаются пути поиска / запуска для зависимостей dylib?
У кого-нибудь есть идеи по поводу того, что яможет быть не так?

Ответы [ 2 ]

12 голосов
/ 21 марта 2012

Как правило, в цели моего dylib я устанавливаю INSTALL_PATH aka «Каталог установки» на нужный мне префикс (например, @executable_path/../Frameworks).

Я оставляю для LD_DYLIB_INSTALL_NAME aka «Имя установки динамической библиотеки» значение по умолчанию, равное $(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH).

Xcode расширяет его, основываясь на имени вашей цели, так что, например, оно может быть @executable_path/../Frameworks/MyFramework.framework/Versions/A/MyFramework.

Важно понимать, что путь установки встроен в dylib, как часть его процесса сборки. Позже, когда вы связываете B.dylib, который ссылается на A.dylib, путь установки A.dylib копируется в B.dylib. (Это то, что otool показывает вам - эти скопированные пути установки.) Поэтому лучше всего сначала получить правильный путь установки, встроенный в dylib.

Прежде чем пытаться заставить все дилибы работать вместе, проверьте каждую по отдельности. Постройте его, затем otool -L на встроенном дизелибе. Первая строка для каждой архитектуры должна соответствовать тому, что LD_DYLIB_INSTALL_NAME показывал вам.

Как только вы это организовали, попытайтесь связать друг с другом дилибов. Это должно быть намного проще.

2 голосов
/ 21 декабря 2015

install_name_tool очень полезно для задания имен и путей.Это особенно полезно, если программа запускает самопроверку в каталоге сборки, а затем все меняется во время make install.В этом случае вы можете использовать install_name_tool без необходимости отдельной сборки.

install_name_tool также полезно, потому что Apple LD не поддерживает опции компоновщика rpath, как Linux / GCC.То есть вам нужно использовать другой набор команд для их установки.

Вот справочная страница для него.Он включен полностью, потому что обсуждаются другие варианты, такие как -headerpad_max_install_names. 

INSTALL_NAME_TOOL(1)                                      INSTALL_NAME_TOOL(1)

NAME
       install_name_tool - change dynamic shared library install names

SYNOPSIS
       install_name_tool  [-change  old  new  ]  ...  [-rpath  old  new  ] ...
       [-add_rpath new ] ... [-delete_rpath new ] ... [-id name] file

DESCRIPTION
       Install_name_tool changes the dynamic shared library install names  and
       or  adds,  changes  or  deletes the rpaths recorded in a Mach-O binary.
       For this tool to work when the install names or rpaths are  larger  the
       binary  should  be  built  with  the ld(1) -headerpad_max_install_names
       option.

       -change old new
              Changes the dependent shared library install name old to new  in
              the specified Mach-O binary.  More than one of these options can
              be specified.  If the Mach-O binary does  not  contain  the  old
              install  name  in  a  specified  -change  option  the  option is
              ignored.

       -id name
              Changes the shared library  identification  name  of  a  dynamic
              shared  library  to name.  If the Mach-O binary is not a dynamic
              shared library and the -id option is specified it is ignored.

       -rpath old new
              Changes the rpath path name old to new in the  specified  Mach-O
              binary.   More  than  one of these options can be specified.  If
              the Mach-O binary does not contain the old rpath path name in  a
              specified -rpath it is an error.

       -add_rpath new
              Adds  the  rpath  path  name new in the specified Mach-O binary.
              More than one of these options can be specified.  If the  Mach-O
              binary  already  contains  the  new rpath path name specified in
              -add_rpath it is an error.

       -delete_rpath old
              deletes the rpath path name old in the specified Mach-O  binary.
              More  than one of these options can be specified.  If the Mach-O
              binary does not contains the old rpath path  name  specified  in
              -delete_rpath it is an error.

SEE ALSO
       ld(1)
...