win32 python as a dll?

[Gordon McMillan]

 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