У меня есть модуль Python, который содержит расширение C ++, а также разделяемую библиотеку, от которой зависит расширение C ++. Совместно используемая библиотека выбирается setuptools как extra_object для расширения. После запуска python setup.py bdist_wheel объект колеса модуля, сгенерированный должным образом, имеет структуру каталогов следующим образом:
+-pymodule.whl
| +-pymodule
| +-pymodule-version.dist-info
| +-extension.so
| +-shared_lib.so
Чтобы установить это колесо, в моей среде python я вызываю pip install pymodule.whl, которая копирует исходные коды python, а также файлы .so в каталог site-packages среды.
После установки модуля можно попытаться импортировать модуль, вызвав import pymodule в терминале для среды. Это вызывает исключение, которое будет выдано:
ImportError: shared_lib.so: cannot open shared object file: No such file or directory
Это исключение можно устранить, добавив соответствующий каталог site-packages к переменной LD_LIBRARY_PATH; однако, кажется, что это должно работать из коробки, особенно с учетом того, что python явно способен найти extension.so.
Есть ли способ заставить python найти эту общую библиотеку без необходимости явно указывать LD_LIBRARY_PATH в месте установки (т.е. site-packages)?
Этот вопрос решает аналогичную проблему, используя данные пакета и явно указывая место установки для общей библиотеки. Проблема, с которой я столкнулся при таком подходе, заключается в том, что общий объект отделен от расширения. В моем случае разделяемая библиотека и расширение являются целями, созданными одной и той же сборкой cmake. Ранее я пытался использовать skbuild для создания расширений на основе cmake; однако, согласно этой проблеме , в skbuild существует аналогичная проблема с включением других библиотек, созданных как часть сборки расширения.