Solution for python22_d.lib

[Martin v. Loewis]

seb_haase at yahoo.com (Sebastian Haase) writes:

> I'm just saying: Why do I need to touch _DEBUG at all? Normally if I
> compile my code in debug-mode _DEBUG is defined -- thats just how
> people are doing that. (As I understand...)

Yes. And normally, on Windows, you also need to use the debug
libraries of everything - whether you want to debug them or not.

> The story just goes the other way around: Why wants the python.h force
> us to include a lib (python22_d.lib)  that it doesn't ship. (And I'm
> _not_ interested in debugging the python lib anyway?)

This is not because we want you to debug Python, but because
otherwise, things may go wrong.

> What was this comment though about the "linking the MSVC debug C libs"
>  -- might this issue cause me trouble ?? I'm not experiencing any
> problems so far...

No, they are unlikely, and if they happen, they are obscure and hard
to find.

Just visit the modules list in the VC++ debugger when you have the
debug version of your extension loaded, but you are linking to the
nodebug version of Python.

You will notice that you have two libraries loaded: msvcrt.dll (or
msvcrt40.dll), which is the no-debug C library, that was loaded
because python22.dll requires that DLL. You will also notice that
msvcrt40d.dll is loaded, which is the debug version of the C library.

Now, both copies of the C library have the same global data structures
- but you get them twice now. This involves in particular the heap: if
you invoke malloc with one of the functions, and free with the other,
bad things may happen - at a minimum, the memory will leak. Microsoft
advises against such scenarios, but I can't find the relevant MSKB
article right now.

Regards,
Martin