我正在将一个SWIG包装的C ++库编译成一个python模块，理想情况下，这个库可以分发给个人透明地像模块一样使用库。我在OSX 10.8.2上使用cmake和swig构建库（系统框架 - Apple python2.7.2，安装框架 - python.org python 2.7.5）
我遇到的麻烦是，在与框架链接后，编译的库非常选择正在运行的python版本，即使otool -L显示它使用“compatability version 2.7.0”编译。似乎不同的发行版具有略微不同的链接符号，并且东西开始中断
最常见的问题是它使用Fatal Python error: PyThreadState_Get: no current thread崩溃python内核（根据：this question，表示链接不兼容）。我可以让我的库在编译的python中工作。
不幸的是，这个图书馆是用于学术实验室，有各种年龄和操作系统的计算机，其中许多都是永久弃用的，以便运行多年未更新的专有软件，我当然不会有时间玩IT并修复所有这些，目前我刚刚编译了最新的Enthought发行版附带的python版本，因为大多数计算机可以以这种或那种方式获得它。我使用的很多研究人员都使用了一些特定于他们的领域的python IDE，它带有一个内置的解释器，但是不可修改而且不是Framework构建（因此我无法构建它），暂时，他们可以在Enthought中运行他们的实验脚本作为一个止损，但它并不理想。即使我链接的python.org发行版与内置的IDE python版本相同（2.7.2我认为它甚至具有相同的版本号），它仍然以同样的方式打破。
在任何情况下，问题是，有没有办法链接一个SWIG包装的python库，以便它运行（至少在OSX上），无论解释器是什么导入它（给定某些最小条件，如保证是＆GT; = 2.7.0）
。修改
使用cmake
中的以下链接器标志针对canopy / python安装版本进行编译 set (CMAKE_SHARED_LINKER_FLAGS "-L ~/Library/Enthought/Canopy_32bit/User/lib -ldl -framework CoreFoundation -lpython2.7 -u _PyMac_Error ~/Library/Enthought/C\
anopy_32bit/User/lib")
在使用otool检查链接库时会产生@rpath符号路径，似乎在其他OSX系统上使用enthought / canopy工作正常，-lpython似乎是可选的，它添加了一个库中引用osx python（非system python）的附加python符号
使用以下链接器标志
编译系统python set (CMAKE_SHARED_LINKER_FLAGS "-L /Library/Frameworks/Python.framework/Versions/Current/lib/python2.7/config -ldl -framework CoreFoundation -u _PyMac_Error /Library/Frameworks/Python.framework/Versions/Current/Python")
在enthought和system python中工作
这些都不能与带有psychopy的捆绑python一起工作，这是目标环境，针对捆绑的python进行编译可以使用psychopy，但没有其他python。
答案 0 :(得分：0)
我一直遇到同样的错误/遇到同样的问题。如果你找到了解决方案，我会很感兴趣。
我发现，如果我针对本机python include目录进行编译并运行本机OS X python二进制文件/usr/bin/python，那么它总能正常工作。即使我编译了一些其他python库（就像我在/Applications/Canopy.app/appdata/canopy-1.0.3.1262.macosx-x86_64/Canopy.app/Contents/include找到的那个），我也可以使本机OS X解释器工作得很好。
我似乎无法让Enthought版本工作。您正在编译哪个目录与Enthought / Canopy一起使用？
在安装时配置SWIG似乎还有一些问题需要了解特定的python库，但这可能不相关：http://swig.10945.n7.nabble.com/SWIG-Installation-mac-osx-10-8-3-Message-w-o-attachments-td13183.html