所有可用的 swig+python+mingw 编译信息是否已过时?
我正在尝试使用 swig 为 python 构建 C++ 扩展。我已按照以下说明和其他说明进行操作,但似乎无法加载我的扩展程序。
我在 MinGW 网站的“如何创建 Python 扩展?”下看到了这篇文章。
我还找到了这些教程:
http://boodebr.org/main/python/build-windows-extensions http://www.mail-archive.com/[电子邮件受保护] /msg04655.html http://oldwiki.mingw.org/index.php/Python%20extensions
我正在使用 Panda3d-1.7.0 来构建 - win32 上的 panda 正在运行 python2.6.4 (MSC v.1500 编译)。我使用 MinGW gcc/g++ (GCC) 3.4.5 进行编译。
我注意到,当我使用以下命令运行 setup.py 时:
python setup.py build -cmingw32
首先运行 gcc.exe,然后运行 g++.exe 来构建 pyd。 g++ 正在链接: -lpython26 -lmsvcr90
她构建并链接得足够好(没有错误),但是,当我将 _extension.pyd 和 extension.py 文件复制到 Panda3d-1.7.0\python\Lib\site-packages 并运行时>从命令行 python -c“导入扩展”,Python 转储以下内容:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 25, in <module>
_bullet = swig_import_helper()
File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 21, in swig_import_helper
_mod = imp.load_module('_extension', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
有任何提示或指示吗?谢谢!
CT
I'm trying to build a C++ extension for python using swig. I've followed the instructions below and the others to a T and can't seem to get my extension to load.
I ran across this article on the MinGW site under "How do I create Python extensions?"
I also found these tutorials:
http://boodebr.org/main/python/build-windows-extensions
http://www.mail-archive.com/[email protected]/msg04655.html
http://oldwiki.mingw.org/index.php/Python%20extensions
I'm using Panda3d-1.7.0 to build against - panda on win32 is running python2.6.4 (MSC v.1500 compiled). I'm using MinGW gcc/g++ (GCC) 3.4.5 to compile.
I've noticed that when I run setup.py with the following command:
python setup.py build -cmingw32
gcc.exe runs first, then g++.exe to build the pyd. g++ is linking against: -lpython26 -lmsvcr90
she builds and links well enough (no errors) but, when I copy the _extension.pyd and extension.py files over into Panda3d-1.7.0\python\Lib\site-packages and run > python -c "import extension" from the command line, Python dumps the following:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 25, in <module>
_bullet = swig_import_helper()
File "C:\Panda3D-1.7.0\python\Lib\site-packages\extension.py", line 21, in swig_import_helper
_mod = imp.load_module('_extension', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
Any tips or pointers? Thanks!
ct
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
需要验证两件事:
使用 dependency walker 检查绑定到 python 和扩展 DLL 的 C 运行时库 DLL 确保它们使用相同的 CRT。在为其他语言构建扩展时,这是一个常见的麻烦来源。 (例如,我经常在 Lua 中看到这种情况),并且可能会导致特别难以追踪的有趣且间歇性的错误。
IIRC,Windows 的“官方”Python 版本已从 MinGW 切换到 Visual Studio Express。由于 C++ ABI 中存在不可调和的差异,这可能导致几乎不可能使用 MinGW 构建可从与 Visual Studio 编译和链接的 Python 调用的 C++ 扩展。
这两者加起来就是建议,以确保您在扩展 DLL 中假设的 ABI 与托管应用程序假设的 ABI 相匹配,并且您不会复制基本功能块,例如可能包含或管理以下状态的 CRT:很难在实例之间正确共享。
编辑:问题的改进编辑强烈表明 Microsoft 的 C++ ABI 和 GCC C++ ABI 之间存在不匹配的问题,这些问题是 已知不同。
Two things to verify:
Check the C runtime library DLL bound to your python and to your extension DLL with dependency walker to make sure that they are using the same CRT. This is a common source of trouble when building extensions for other languages. (I see it often with Lua, for instance) and can cause interesting and intermittent bugs that are particularly difficult to track down.
IIRC, the "official" Python releases for Windows have switched to Visual Studio Express from MinGW. This may make it nearly impossible to use MinGW to build a C++ extension that can be called from a Python compiled and linked with Visual Studio due to irreconcilable differences in the C++ ABI.
Both of these add up to advice to make sure that the ABI you are assuming in your extension DLL matches the ABI assumed by the hosting application, and that you aren't duplicating fundamental functional blocks such as the CRT that might contain or manage state that is difficult to correctly share between instances.
Edit: The improved edit of the question speaks strongly to there being issues with mismatches between Microsoft's C++ ABI and the GCC C++ ABI which are known to differ.