Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Puzzling dependency of Boost.Python 1.54 (debug build) to Python27.lib on Windows

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

like image 513
François Beaune Avatar asked Dec 25 '22 18:12

François Beaune


1 Answers

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.

like image 168
François Beaune Avatar answered Dec 28 '22 19:12

François Beaune