问题描述
我有一个python扩展模块(2.7)(由swig生产)，它本身链接到链接到Python 3.33的库.甚至将模块链接到版本3.33，在实例化该模块时，它也会调用由2.7定义的PyFunc，而不是在3.33中定义的PyFunc.这仅在linux上发生，并且在Windows上运行良好.我是否需要通过特定的链接器标志来避免此类问题?
I've a python extension module (2.7) (produced by swig), that itself links to a library linked to Python 3.33. Even the module is linked to the version 3.33, when it is instantiated, it calls the PyFunc defined by the 2.7 instead of the ones defined in the 3.33. This happens only on linux , and works good on Windows. Do I need to pass specific linkers flag to avoid this kind of issue ?
谢谢！
推荐答案
在Windows下，DLL(Linux共享对象类似物)必须在链接阶段(因此在构建期间)解析其所有外部符号.在您的扩展程序中，该扩展程序是通过python 3.0 DLL隐式链接的，并且一切正常(没有看到MSVC命令行，我几乎可以确定该扩展程序是通过位于c:/python33/libs/python33.lib之类的存根库链接的)
Under Windows, DLLs (Linux shared objects analogue) must resolve all of their external symbols during the link phase, so during the build of your extension, the extension is implicitly linked w/ python 3.0 DLL and everything is working just fine (w/o seeing MSVC command line, I'm almost sure the extension is linked w/ stub library located under something like c:/python33/libs/python33.lib)
另一方面，在Linux下，共享库默认链接机制，因此-lpython的LD规范可能会在运行时解析为基于2.7的加载共享对象...
Under Linux on the other hand, shared objects default link regime isn't resolving all the external symbols, hence the LD specification of -lpython will probably resolved during runtime to the loaded shared objects which is 2.7 based ...
所以您有2个选择:
-
有了源代码之后，在Linux下，您可以通过
dlopen动态加载libpython33.so以避免这种"DLL地狱"
Since you got the sources, under Linux you can load libpython33.so via
dlopendynamically to avoid this "DLL hell"
静态方法，应指定python3.3的 exact 位置，即代替/usr/lib/python3.3/libpython33.so
static approach, you shall specify the exact location of python3.3 i.e. instead of the "vague" -lpython (which resolved to python2.7) something like /usr/lib/python3.3/libpython33.so
这篇关于具有嵌入式python的Python扩展模块调用错误的库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！