& Quot; DLL-путь & Quot; не имеет никакого эффекта при наращивании буста

Question

& Quot; DLL-путь & Quot; не имеет никакого эффекта при наращивании буста

Я стремлюсь иметь полные пути выполнения в скомпилированных библиотеках повышения 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 на каждой библиотеке)?

3

boost c++dll install-name-tool otool

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Почему полезны свойства 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 в нестандартных местах установки:

Согласно https://stackoverflow.com/a/33893062/4313507 , Обновите пути в установленных файлах общей библиотеки (используя жестко заданный путь или 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
```

0