"dll-path" не действует при наращивании буста

Question

"dll-path" не действует при наращивании буста

Я стремлюсь иметь полные пути выполнения в скомпилированных библиотеках boost, предоставляя dll-path опция при компиляции boost:

$ ./b2 dll-path=$(pwd)/build --prefix=$(pwd)/build
$ ./b2 install dll-path=$(pwd)/build --prefix=$(pwd)/build

Тем не менее, когда я проверяю библиотеки в $(pwd)/build папка у меня такая:

$ otool -L build/lib/libboost_system.dylib 
build/lib/libboost_system.dylib:
    libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

Т.е. вместо полного пути с именем lib есть просто имя lib (libboost_system.dylib). Как следует использовать dll-path вариант или есть "официальный" способ добиться этого (кроме наличия сценария, который запускается вручную install_name_tool на каждой библиотеке)?

4

c++ boost dll otool install-name-tool

Источник

user846340 12 ноя '15 в 09:09

1 ответ

Другие вопросы по тегам c++ boost dll otool install-name-tool

user4313507 25 июн '18 в 20:13 2018-06-25 20:13 · Answer 1 · 2018-06-25 20:13

Почему полезны свойства dll-path и hardcode-dll-paths?

Однако для запуска приложения в зависимости от разделяемых библиотек ОС может потребоваться найти разделяемую библиотеку при запуске приложения. Динамический компоновщик будет искать в заданном системой списке путей, загружать библиотеку и разрешать символы. Это означает, что вы должны либо изменить системный список, заданный переменной среды LD_LIBRARY_PATH, либо установить библиотеки в системном расположении. Это может быть неудобно при разработке, поскольку библиотеки еще не готовы к установке, а перегруженные системные пути могут быть нежелательны. К счастью, в Unix есть другой способ.
Исполняемый файл может включать в себя список дополнительных путей к библиотекам, которые будут искать перед системными путями. Это отлично подходит для разработки, потому что система сборки знает пути ко всем библиотекам и может включать их в исполняемые файлы. Это делается, когда функция hardcode-dll-paths имеет истинное значение, которое является значением по умолчанию. Когда исполняемые файлы должны быть установлены, история другая.
Очевидно, что установленный исполняемый файл не должен содержать жестко заданных путей к дереву разработки. (По этой причине правило установки явно отключает функцию hardcode-dll-paths.)

Моя интерпретация этой документации заключается в том, что Boost ожидает, что ее библиотеки будут установлены в стандартном системном расположении. Нестандартные локации можно использовать для разработки самого Boost, используя dll-path а также hardcode-dll-paths свойства, но эта функция явно отключена в install Правило процесса сборки Boost:

Кажется, что есть несколько вариантов использования общих библиотек Boost в нестандартных местах установки:

Согласно /questions/44033357/zavisimosti-ot-biblioteki-nadstrojki-ne-imeyut-polnogo-puti/44033358#44033358, обновите пути в установленных файлах общей библиотеки (используя жестко заданный путь или RPath):
```
install_name_tool libboost_regex.dylib -id @rpath/libboost_regex.dylib
```
Помните, что некоторые компоненты Boost ссылаются друг на друга, поэтому обязательно обновите пути и внутренних ссылок. Пример:
```
$ otool -L libboost_filesystem.dylib
libboost_filesystem.dylib:
  libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
  libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
```
Использовать LD_LIBRARY_PATH переменная окружения, чтобы помочь найти общие библиотеки. Пример:
```
LD_LIBRARY_PATH=$HOME/local/lib exe_name
```