Python Programming On Win32

Debug Versus Release Builds

A couple of times now, we have glossed over some differences between debug and release builds for our extensions and Python. This is a symptom of the important, although somewhat technical, issue of the C runtime library.

If you don’t know what a C runtime library is or don’t care about the technical details, the simple rules to follow are:

• Release builds of your project must use the Multithreaded DLL and link with the standard Python .lib files.

• Debug builds of your project must use the Debug Multithreaded DLL C run-time library, must link with the _d version of the Python .lib files, and must themselves be named following the _d convention.

This is simple to set up, as we demonstrated when building the spam sample. The compile tool described previously automatically creates the correct settings, so in some cases you don’t need to do anything. However, a deeper understanding of the issues will help you understand why the _d convention exists and how to exploit or work around it for your situation. Feel free to skip the rest of this section.

The underlying issue is that Python and its extensions are DLLs, and these DLLs need the same C runtime library. Particularly at issue are FILE objects and memory allocated via malloc(). If all Python extensions aren’t using the same C runtime library, the FILE objects passed between Python and the extensions are considered invalid. The result is likely to be an access violation.

Although this problem isn’t unique to ...