Python loading library containing embedded python...
"Martin v. Löwis"
martin at v.loewis.de
Mon Jan 30 06:49:22 CET 2006
> I compiled pythoncore.lib. I statically link this to my dll
> and define Py_BUILD_CORE before including Python.h.
Can you please elaborate? How did you do this? How do you know
pythoncore.lib is a static library? What msvcrt is it linked
with (use depends.exe to find out)?
> The only difference I can see with doing this vs linking the
> python dll dynamically is that Py_IsInitialized returns true
> when using the dll. This makes sense, but little else does.
You should explicitly call Py_Initialize in your embedded
application. Py_Initialize should return false before you
do so, and true afterwards. If that is not the case (e.g.
if Py_Initialize returns true even though you haven't called
Py_Initialize), something is wrong.
> For now, I am testing this in Windows with Visual Studio.
> I will look into renaming the symbols, but I am not sure
> I understand why this is necessary. Surely two unrelated
> DLLs can exist in a process with the same function names?
On Windows, yes. Not on Unix, atleast not in general.
> If not, I am surprised this problem hasn't been seen or
> even exploited by plugin competitors more often.
For plugins, there is a real problem on Unix, with several
strategies to solve it available. Avoiding naming conflicts
in the first place is the only one that really works,
independently of the plugin host.
More information about the Python-list