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 2.7.5 (all three from slightly earlier minor versions), the Python bindings of my project no longer link in Debug configuration (they link fine in Release). I'm building with VS 2012. Everything was working properly before the update.
I built Boost the standard way: bootstrap.bat followed by b2 address-model=64 toolset=msvc-11.0. My system has a Python 2.7 installation which is picked up by b2:
notice: [python-cfg] Configuring python...
notice: [python-cfg] Registry indicates Python 2.7 installed at "C:\Python27\"
notice: [python-cfg] Checking interpreter command "python"...
notice: [python-cfg] running command 'DIR /-C /A:S "C:\Python27\python.exe" 2>&1'
notice: [python-cfg] running command 'python -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1'
notice: [python-cfg] ...requested configuration matched!
notice: [python-cfg] Details of this Python configuration:
notice: [python-cfg] interpreter command: "python"
notice: [python-cfg] include path: "C:\Python27\Include"
notice: [python-cfg] library path: "C:\Python27\libs"
notice: [python-cfg] DLL search path: "C:\Python27"
I don't have any other Python installation on my machine.
When I run CMake on my project, everything looks good too:
Found PythonLibs: optimized;C:/Python27/libs/python27.lib;debug;C:/Python27/libs/python27_d.lib (found version "2.7.5")
The relevant part of the linker's command line in Debug is as expected:
"C:\franz\dev\boost_1_54_0\stage\lib\libboost_python-vc110-mt-gd-1_54.lib" "C:\Python27\libs\python27_d.lib"
When I finally build the project in Debug:
LINK : fatal error LNK1104: cannot open file 'python27.lib'
Since nowhere is python27.lib mentioned on the linker's command line, I edited libboost_python-vc110-mt-gd-1_54.lib with an hexadecimal editor only to find out that it contains references to python27.lib (of the form /DEFAULTLIB:"python27.lib") where I would have expected references to python27_d.lib instead (of which there is none).
Am I doing something wrong when building Boost? Is this a known problem with Boost.Python in Boost 1.54? Any help would be greatly appreciated.
Update #1: I tried again with Boost 1.51 and 1.50 and the same problem occurs, so it's not a regression in Boost.
Update #2: I removed the debug version of the Python lib (python27_d.lib) from my Python installation, thus reverting to a vanilla Python installation. I then rebuilt Boost 1.51 and my project (with CMake reporting a single library file as expected: Found PythonLibs: C:/Python27/libs/python27.lib (found version "2.7.5")). The problem persists, however the error message now mentions python27_d.lib: LINK : fatal error LNK1104: cannot open file 'python27_d.lib'!
Update #3: Using Process Monitor I could that python27_d.lib is not searched in C:\Python27\libs\ where it actually resides:
3:35:28.0550683 PM link.exe 10132 CreateFile C:\franz\dev\appleseed\build\appleseed.python\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0551846 PM link.exe 10132 CreateFile C:\franz\dev\boost_1_50_0\stage\lib\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0552474 PM link.exe 10132 CreateFile C:\franz\dev\boost_1_50_0\stage\lib\Debug\python27_d.lib PATH NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0553595 PM link.exe 10132 CreateFile C:\franz\dev\appleseed\build\appleseed.python\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0556105 PM link.exe 10132 CreateFile C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\lib\amd64\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0559637 PM link.exe 10132 CreateFile C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\lib\amd64\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0560984 PM link.exe 10132 CreateFile C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64\python27_d.lib NAME NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
3:35:28.0561741 PM link.exe 10132 CreateFile C:\franz\dev\appleseed\build\appleseed.python\python27_d.lib NAME NOT FOUND Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a
Update #4: related question: Visual C++ debug library naming convention
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.
Including boost/python/detail/wrap_python.hppinstead 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.
来源：https://stackoverflow.com/questions/19716859/puzzling-dependency-of-boost-python-1-54-debug-build-to-python27-lib-on-window