我正在构建一个具有多个需要 libhdf5 的 C 扩展的 Python 项目。我在 /usr/local/lib 处安装了 libhdf5 .对于测试和开发，我想针对位于 /Users/name/some/path 的 HDF5 私有(private)版本进行开发。 .
在 setup.py 中，我通过将“library_dirs”(和“runtime_library_dirs”，尽管在 OS X 上不执行任何操作)设置为 /Users/name/some/path 来处理这个问题.在 Linux 上，这工作正常。
问题是，当我的扩展模块被编译时，它们链接到 /usr/local/lib 中的 HDF5 副本。 setup.py 中再多的调整也无法说服他们。
通过设置DYLD_LIBRARY_PATH=/Users/name/some/path运行 Python 时，我已成功加载 HDF5 的私有(private)构建，因此我知道该库已正确构建并且可以运行。
正在运行 otool -L在我的一个扩展上产生了这个:
h5py/_errors.so:
/usr/local/lib/libhdf5.8.dylib (compatibility version 9.0.0, current version 9.1.0)
/usr/local/lib/libhdf5_hl.8.dylib (compatibility version 9.0.0, current version 9.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
这确认我们正在链接到库的错误副本。 我注意到链接阶段看起来像这样:
clang -bundle -undefined dynamic_lookup -L/usr/local/lib -L/usr/local/opt/sqlite/lib -L/Users/name/some/path <more stuff>
并推测 clang 正在链接它能找到的第一个版本的 HDF5。
有没有办法强制 distutils 链接到我的私有(private)图书馆？我不需要可重定位版本，所以我不关心 @rpath等
我还确认系统 Python 不会发生这种情况，只有通过 Homebrew 软件安装的系统才会发生这种情况。
最佳答案
我的简短回答是:不要使用 HomeBrew Python 来管理 Homebrew 软件之外的构建。你可以在这里看到:https://github.com/Homebrew/homebrew/blob/master/Library/Formula/python.rb#L213他们已经将他们的库标志硬编码到 Python Makefile 本身。
当然，解决您的问题的答案更有趣:)
如果你真的想要，你可以通过猴子补丁 sysconfig.get_config_vars() 来在系统库之前注入(inject)你的标志。你也可以猴子补丁 distutils。这些都不是特别健壮。
在 HashDist 中，我们优先构建我们自己的 Python，这令人沮丧，但我们发现它是最健壮的。 (我们在 OS X 上支持 h5py)
关于python - Homebrew 软件/Python : Convince distutils to link against a specific library on OS X?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21443361/