Как мне найти библиотеки для их динамической загрузки с помощью dlopen

Question

В проекте, над которым я работаю, мы предоставляем возможность динамически загружать дополнительные функции.Для этого мы используем dlopen.

Чтобы найти эти библиотеки, у нас есть то, что мы называем путь к модулю.Там у нас есть путь по умолчанию, в котором находятся общие библиотеки (многие из них поставляются).

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

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

Нет вопроса: есть ли хитрость (либо в C ++, либо в системе сборки), чтобы узнать, установлено приложение или нет.Проблема в том, что функциональность реализована в разделяемой библиотеке, и реализованный способ поиска модулей должен работать и для других приложений, которые ссылаются на нашу библиотеку (поэтому мы не можем полагаться на путь исполняемого файла).Мы используем CMake в качестве системы сборки.

Чтобы сделать ситуацию еще сложнее, решение должно работать на Windows, Linux и Mac OS X.

РЕДАКТИРОВАТЬ:

IВ дальнейшем исследуется и проблема более сложная.Это ситуация:

• Есть небольшой исполняемый файл
• Кроме того, есть "основная" библиотека main.so
• , а затем динамически загружаемая библиотекаlib.so
• lib.so ссылается на main.so

Проблема в том, что lib.so имеет абсолютный путь к main.so в каталоге сборки в своем rpath.Благодаря подсказке @MSalters я теперь смог взломать, чтобы убедиться, что загружена правильная версия lib.so (та, что находится в каталоге установки), но, поскольку он имеет путь сборки в rpath, он загружает неправильный главный.so (так что на самом деле в памяти есть две копии main.so - это все портит).

Есть ли способ удалить эту ссылку на путь сборки из библиотеки?Я безуспешно перепробовал все параметры cmake, связанные с rpath

Answer 1

Не можете ли вы проверить, где находится сам исполняемый файл?Если он находится в каталогах сборки, используйте библиотеки сборки - если он находится в установке, используйте install?

getcwd() имеет эквиваленты на всех этих платформах, но это может быть не то, что вам нужно - это зависито том, как вы запускаете исполняемый файл.

Я думаю, что расположение процесса зависит от конкретной системы, но это не должно быть слишком сложно, чтобы обернуть это.

Answer 2

У установленной версии не должно быть каталога сборки в rpath.

Возможно, вы захотите выполнить связывание дважды (один раз для версии сборки и один раз для установленной версии).Обычно в системах * nix установленный двоичный файл имеет некоторый статический путь, по которому он пытается найти плагины.Вы можете определить некоторую переменную среды (или аргумент командной строки), чтобы перегрузить ее для выполнения сборки (и использовать скрипт-обертку, чтобы установить ее в среде сборки).

Проверьте, как она решается некоторыми проектами (Например, Firefox).

Я не очень разбираюсь в системе Windows, но думаю, что стандартный способ сделать это - найти плагины в том же каталоге, что и исполняемый файл.