Чтобы ответить на вопрос:
почему это происходит только для библиотек повышения и не происходит с другими зависимостями, от которых зависит моя библиотека?
Техническая причина заключается в том, что система сборки Boost (bjam) явно присваивает имя установки библиотеки только имя файла. Это могло быть сделано внутри с помощью параметра компилятора -install_name.
Что касается обоснования этого, я не могу говорить за разработчиков Boost, поэтому я мог только строить догадки (что является плохой формой инвестиции): жесткое кодирование локального пути установки в библиотеке только откладывает ошибку времени выполнения библиотеки до времени распространения, поэтому они могут просто захотеть, чтобы вы правильно устранили ее, как только время разработки. (Или это могло быть просто устаревшее поведение, которое они не хотели тратить на переработку;)
Возможные решения
Давайте представим, что ваша динамическая библиотека (которая зависит от Boost) называется myLib. Как вы уже указали в своем вопросе, вы вполне можете изменить имя установки для библиотек Boost, записанное в myLib:
install_name_tool myLib -change libboost_regex.dylib /full/path/to/libboost_regex.dylib
Альтернативой является изменение имени установки самих библиотек Boost:
install_name_tool libboost_regex.dylib -id $new_name
При таком подходе имя установки $new_name теперь будет записано в myLib при сборке с модифицированным libboost_regex.dylib.
Вы знаете, что должны решить, какое значение присвоить $new_name. Конечно, это может быть полный путь к библиотеке, и таким образом библиотеки Boost будут вести себя как другие ваши зависимости.
Альтернативой, которую легче распространять, является использование RPath. (Имена установки на основе RPath возлагают на зависимого бремя поиска своей зависимости: зависимый хранит список путей, которыми он попытается заменить @rpath):
install_name_tool libboost_regex.dylib -id @rpath/libboost_regex.dylib #assign a rpath dependant install name to a boost library
install_name_tool myLib -add_rpath $a_rpath_prefix # adds a candidate to substitute @rpath with, stored in myLib
$a_rpath_prefix может быть путем к папке, содержащей ваши библиотеки Boost, которые будут хорошо работать в вашей среде разработки. И если однажды вам понадобится распространить свою библиотеку, вы можете встроить зависимости Boost в относительный путь (или в пакет OS X) и добавить значение RPath, которое будет следовать этому относительному пути.
Изменить вопрос
Для конкретного описанного вами случая автоматической проверки, которая не может найти Boost, вы, вероятно, можете решить ее с помощью альтернативного решения, предложенного выше. Он изменяет имя установки библиотеки Boost, которая хранится в самой библиотеке (и, таким образом, будет скопирована в libA.dylib):
install_name_tool libboost_regex.dylib -id /full/path/to/libboost_regex.dylib
В этом конкретном случае использования еще более простым решением может быть заполнение DYLD_FALLBACK_LIBRARY_PATH путем к каталогу, содержащему вашу библиотеку Boost. Динамический компоновщик будет искать библиотеки в этих каталогах, поэтому он найдет там библиотеки boost. В терминале, в котором будет запускаться проверка сборки:
export DYLD_FALLBACK_LIBRARY_PATH=/full/path/to/;$DYLD_FALLBACK_LIBRARY_PATH
person
Ad N
schedule
24.11.2015
