win32 python as a dll?
Gordon McMillan
gmcm at hypernet.com
Fri Jul 9 13:54:50 EDT 1999
Scott Wolford wrote:
> Mark Hammond wrote:
[debug python builds on Windows]
> How about:
> python.lib/dll and msvcrt.lib/dll
> python.lib/dll and msvcrtd.lib/dll
> python_d.lib/dll and msvcrt.lib/dll
> python_d.lib/dll and msvcrtd.lib/dll
Debug python linked to non-debug msvcrt makes sense - means you can
load non-debug extension modules (see below).
> > It is also worth noting that Gordon pointed this out to you before this
> > particular thread, and you still had the problem. Im not sure that
> > documenting it would be effective in all cases.
>
> He said to use the Multithreaded DLL. Unfortunately, msvcrt.dll and
> msvcrtd.dll are *both* the Multithreaded DLL; one is debug the other
> is not. It never occured to me (well, it finally did) that it
> mattered whether msvcrt.dll or msvcrtd.dll were used. I assumed that
> the semantics of the two DLLs were essentially the same, just the
> implementation differed slightly. I'm pretty sure (though I haven't
> tested it, maybe you'll know) that you can mix and match optimized
> and debug code pretty easily under Unix.
To beat a dead horse into an unrecognizable pulp:
That's the whole point - they are *different* dlls. So a file open in
one will not be found in the other. Kaboom. Nothing to do with
semantics - it's just where buffers, files and other statics /
globals live.
You can mix debug and optimized in Windows, too - you'll just end up
stepping thru unintelligable assembler when you hit non-debug code.
[And for the masochistically curious - the reason the runtime lib is
specified to the MSVC compiler and not the linker is that the
compiler generates slightly different code depending on whether the c
runtime is in a static lib or in a dll.]
- Gordon
More information about the Python-list
mailing list