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
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
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
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 ...