On 24/08/2012 4:00 AM, Will Sadkin wrote:
Hi all,
I have a bit of a stumper. We have a C++ program in which we embed a
release python interpreter, so that both our C++ and python programs can
share a single codebase, written in Python. When building the program
for debug, we always #undef _DEBUG while including Python.h, and always
therefore link with python27.lib, and embed the *release* interpreter.
There are other symbols - it looks like you want to ensure DEBUG also
isn't set and that NDEBUG is.
(We did this so that we don't have to locate and/or build debug versions
of the python interpreteter or extension dlls we may load (eg pyodbc,
mx, etc. At least that was the theory.))
This embedded interpreter ends up importing a python package that tries
to run the line:
from mx import DateTime
From within the release C++ executable, this works just fine. But with
the debug executable, it generates the following exception on that line:
DLL load failed: A dynamic link library (DLL) initialization routine
failed.
I have a hypothesis as to why this is happening, bug am not sure how to
confirm it, nor what to do about it.
I suspect that the python27.dll is a statically linked dll,
I'm not sure what you mean here - if you are talking about the linkage
of the CRT, then it is not static - Python uses the DLL version of the
CRT. You should be able to confirm this with depends.exe, and also by
looking at the "output" tab of MSVC - it should report the CRT being
loaded as python27.dll loads.
and so the
embedded python interpreter I create can run on its own, regardless of
the rest of the dlls linked into the rest of the executable. (This
would be the only way I could see this working at all.) However, the
executable containing that release Python interpreter is still linked
with the debug Microsoft dlls to allow debugging, and I suspect that the
(release) mxDateTime extension pyd is NOT statically linked, and so when
it attempts to load within the embedded framework, it can't because one
of the release DLLs *it* depends on (probably MSVCR90.dll, judging by
the output from depends.exe) is not linked into the executable and/or
conflicts with the MSVCR90D.dll that already is.
That shouldn't be a problem - if all Python components are linked
against the same CRT, life should be OK even if the embedding component
uses a different CRT. Unless, of course, that embedding component
attempts to directly call Python...
As I said, I'm not sure how to confirm this, nor what to do about it,
and I'm hoping Mark Hammond may have some suggestions.
I have a different bug in this program that I really need to track down
in the VS2008 debugger, but I am stymied because this problem occurs
before I can get to the code in question, and so the program doesn't run
the same way in both release and debug versions.
Also note that it might be useful to simply change your release build to
not optimize and to include debug symbols - that should let you step
through the release version and avoids mixing-and-matching CRT versions.
HTH,
Mark
Thanks in advance,
/Will Sadkin
Parlance Corporation
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
