我有一个包含C ++扩展的python模块以及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）？
This通过使用包数据并明确指定共享库的安装位置来解决类似问题。我对这种方法的问题是共享对象与扩展分离。在我的例子中，共享库和扩展都是由相同的cmake构建构建的目标。我以前曾尝试使用skbuild来构建基于cmake的扩展;但是，根据this issue，在skbuild中存在类似的问题，包括作为扩展构建的一部分生成的其他库。