I must be doing some kind of obvious mistake but after hours of fighting I\'m unable to make further progress:
After upgrading to Boost 1.54, CMake 2.8.12 and Python
Including boost/python/detail/wrap_python.hpp
instead of Python.h
allows you to use a release version of Python even when building a debug version of your program.
In case you have compiled yourself a debug version of Python, you can build a debug version of Boost that links against your debug version of Python. (I am using VS2013, but the process should be the same with VS2010 and VS2012).
First create a text file called, eg, my_config.bjam
conatining:
using python : 2.7 #version
: C:\\Python-2.7.10-64bit-dbg-msvc12\\python_d.exe #executable
: C:\\Python-2.7.10-64bit-dbg-msvc12\\include #includes
: C:\\Python-2.7.10-64bit-dbg-msvc12\\libs #libs
: <python-debugging>on ;
In order build a debug version of Boost, run bootstrap.bat
first, then b2
with the following options:
b2 ^
--build-dir=build__64bit-dbg-msvc12 ^
--build-type=complete ^
--stagedir=stage__64bit-dbg-msvc12 ^
--user-config=my_config.bjam ^
address-model=64 ^
python-debugging=on ^
define=BOOST_PYTHON_DEBUG ^
define=BOOST_PYTHON_NO_LIB ^
link=shared ^
toolset=msvc-12.0 ^
variant=debug ^
stage
This should do the trick. You should define BOOST_PYTHON_DEBUG
also when compiling the debug version of your program.
I fixed the problem, thanks to hints found in this post: Visual C++ debug library naming convention.
Basically, the header file pyconfig.h
that ships with Python (in C:\Python27\include\
) forces linking to python27_d.lib
in Debug build (via a #pragma comment()
directive), regardless of whether this library exists or not.
The trick is to never include Python.h
directly, but instead to include Boost's wrapper for that file, boost/python/detail/wrap_python.hpp
which takes care of disabling the offending #pragma comment()
directive.