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. I tried this, but it made no difference. >> (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. Ok, here is what the output window of the attached debugger says as the pyd file loads (I'm running a 32bit version of python27 on my 64bit laptop, which is why the paths all have SysWOW64 and x86 in them, but normally this is running on a 32bit machine.): 'BuildServ.exe': Loaded 'C:\Program Files (x86)\Python27\Lib\site-packages\mx\DateTime\mxDateTime\mxDateTime.pyd', Binary was not built with debug information. 'BuildServ.exe': Loaded 'C:\Windows\SysWOW64\msvcr90.dll', Symbols loaded. 'BuildServ.exe': Unloaded 'C:\Program Files (x86)\Python27\Lib\site-packages\mx\DateTime\mxDateTime\mxDateTime.pyd' 'BuildServ.exe': Unloaded 'C:\Windows\SysWOW64\msvcr90.dll' And yet the pyd import generates the DLL load failure above. [...] > 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... I'm pretty sure I'm not, which leaves me completely mystified as to why mxDateTime won't Initialize properly in my debug executable... > 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. I had tried this before with no success, but I took your advice, and finally figured out how to get symbols and source code access for my release executable, and then tracked down my other bug. Your suggestion makes me wonder what the point of debug executables at all if one can do this, but assuming that there are somethings you can do with a debug exe that you can't with a release exe, I'd still like to know why the debug exe can't load mxDateTime! Regards, /Will _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
