I'm attempting to build Boost from source and running into an odd issue. Some Windows machines can compile this just fine and others fail even though they're all running the same version of Visual Studio. This worked on all machines using Boost 1.62 but is failing with Boost 1.72.
Here's the Boost build command:
b2 -j${num_processors} -d 0 --layout=versioned architecture=x86 address-model=64 threading=multi
link=shared runtime-link=shared toolset=msvc-14.0 --with-system --with-thread --with-date_time
--with-chrono --with-filesystem --with-atomic variant=debug --prefix=${boost_dir} install
The issue seems to be that Boost Thread isn't getting configured properly such that the project's .MANIFEST file is not generated. Here's the error output (see last line):
> bin.v2\libs\headers\build\install\boost_headers-config.cmake
> 1 file(s) copied.
> msvc.link.dll bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.dll
>
> call "bin.v2\standalone\msvc\msvc-14.0\address-model-64\architecture-x86\msvc-setup.bat" amd64 >nul
> link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X64 /MANIFEST /subsystem:console /out:"bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.dll"
/IMPLIB:"bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.lib"
#"bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.dll.rsp"
> if %ERRORLEVEL% NEQ 0 EXIT %ERRORLEVEL%
>
> Creating library bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.lib
and object bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.exp
>LINK : fatal error LNK1104: cannot open file 'bin.v2\libs\thread\build\msvc-14.0\debug\address-model-64\threadapi-win32\threading-multi\boost_thread-vc140-mt-gd-x64-1_72.dll.manifest'
Any ideas what would trigger this or suggestions on what I can investigate further?
EDIT: We're building this on Windows 10 using Visual Studio 2015.
For posterity, the team upgraded to Visual Studio 2019. This at least worked around the issue for most of us. A few folks still have issues.
Related
I have built libtorrent with boost with this commands in the boost root folder :
bootstrap.bat
b2 --hash cxxstd=14 release
and after I have added BOOST_ROOT and BOOST_BUILD_PATH to PATH variable.
I also have downloaded OpenSSL and build it then have copied to Visual studio 15 2017 compiler include and libs folder repectively.
Next in the libtorrent root folder I have run this commands:
b2 variant=release link=shared
b2 install --prefix=build
The build was successful and libtorrent c++ library has created.
and after that I have run these commands :
py setup.py build
py setup.py install
They executed with no errors and libtorrent installed in my python
libs/site-packages folder. But when I import it this error shows:
Python Import Error
[]
What build steps might I have done wrong?
Os : Windows 10 x64
Python : 3.9.5 x64
Libtorrent : 2.0.5
Boost : 1.78.0
I have followed from the libtorrent docs :
https://libtorrent.org/building.html
and
https://www.libtorrent.org/python_binding.html
What did I do ?
Basically following: https://github.com/arvidn/libtorrent/blob/master/docs/building.rst#downloading-and-building
Unzipping boost_1_78_0.zip into D:\boost_1_78_0, and running:
set BOOST_ROOT=D:\boost_1_78_0
set BOOST_BUILD_PATH=%BOOST_ROOT%\tools\build
(cd %BOOST_ROOT% && .\bootstrap.bat)
echo using msvc ; >>%HOMEDRIVE%%HOMEPATH%\user-config.jam
%BOOST_ROOT%\b2.exe --hash release
After this i got:
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:
D:\boost_1_78_0
The following directory should be added to linker library paths:
D:\boost_1_78_0\stage\lib
I think this is where i started to fail, I did not read this the first time, and now I am asking meself where/how should the "compiler include paths" and "linker library paths" be set .?
When trying to compile libtorrent, using the command-line you provided (b2 msvc-14.2 variant=release link=static runtime-link=static debug-symbols=on), i got:
CXXFLAGS =
LDFLAGS =
OS = NT
building boost from source directory: D:/boost_1_78_0
Performing configuration checks
- default address-model : 64-bit (cached) [1]
- default architecture : x86 (cached) [1]
[1] msvc-14.2
...patience...
...patience...
...patience...
...found 3888 targets...
...updating 78 targets...
compile-c-c++ bin\msvc-14.2\release\cxxstd-14-iso\debug-symbols-on\link-static\runtime-link-static\threading-multi\src\hasher.obj
hasher.cpp
D:\TEMP\libtorrent\libtorrent\include\libtorrent/hasher.hpp(66): fatal error C1083: Cannot open include file: 'openssl/sha.h': No such file or directory
call "bin\standalone\msvc\msvc-14.2\msvc-setup.bat" >nul
cl /Zm800 -nologo "src\hasher.cpp" -c -Fo"bin\msvc-14.2\release\cxxstd-14-iso\debug-symbols-on\link-static\runtime-link-static\threading-multi\src\hasher.obj" -TP /bigobj /wd4251 /wd4268 /wd4275 /wd4373 /wd4503 /wd4675 /EHs /std:c++14 /GR /Zc:throwingNew /O2 /Z7 /Ob2 /W4 /MT /Zc:forScope /Zc:wchar_t /Zc:inline /Gw /favor:blend -DBOOST_ALL_NO_LIB -DBOOST_ASIO_ENABLE_CANCELIO -DBOOST_ASIO_HAS_STD_CHRONO -DBOOST_ASIO_NO_DEPRECATED -DBOOST_MULTI_INDEX_DISABLE_SERIALIZATION -DBOOST_NO_DEPRECATED -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -DOPENSSL_NO_SSL2 -DTORRENT_BUILDING_LIBRARY -DTORRENT_SSL_PEERS -DTORRENT_USE_I2P=1 -DTORRENT_USE_LIBCRYPTO -DTORRENT_USE_OPENSSL -DWIN32 -DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE -D_FILE_OFFSET_BITS=64 -D_SCL_SECURE_NO_DEPRECATE -D_WIN32 -D_WIN32_WINNT=0x0600 -D__USE_W32_SOCKETS "-ID:\boost_1_78_0" "-Ideps\try_signal" "-Iinclude" "-Iinclude\libtorrent"
...failed compile-c-c++ bin\msvc-14.2\release\cxxstd-14-iso\debug-symbols-on\link-static\runtime-link-static\threading-multi\src\hasher.obj...
compile-c-c++ bin\msvc-14.2\release\cxxstd-14-iso\debug-symbols-on\link-static\runtime-link-static\threading-multi\src\merkle.obj
merkle.cpp
D:\TEMP\libtorrent\libtorrent\include\libtorrent/hasher.hpp(66): fatal error C1083: Cannot open include file: 'openssl/sha.h': No such file or directory
..... (rest of logging removed)
I found the answer.
While building libtorrent python binding 2 factors are important:
1- openSSL version
2- linking type
python comes with openssl v.1.1 (or similar based on python version) , if building python binding with openssl v.1.1 (which is the latest version while I am writing) one dependency solved otherwise, if using openssl v.3 for building 2 dependency must add to python which they are:
// 32 or 64 bits library based on openssl build
libssl-3-x64.dll
libcrypto-3-x64.dll
2 ) in the time of building python binding 2 commands can be use:
a ) simple with default parameters :
py setup.py build
py setup.py install
In this case in default libtorrent and boost-python linking static.
b ) complex one with more control (I think) :
py setup.py build_ext --b2-args="VARS" install
In the VARS place we can write boost build options but these are the one we want:
libtorrent-link=TYPE boost-link= TYPE
TYPE can be static or shared but anyone that sets shared , it becomes dependency. two files which is in need are :
// 32 and 64 bits file may have different name
// files can have different names but they are similar to below
torrent-rastarbar.dll
boost_python(PYTHON-VERSION)(SOME-INFO).dll
boost python can be find in the boost root directory in the stage/lib .
pleae note that you must build boost and libtorrent SHARED for this solution.
Conclusion :
as mentioned above these dependency must add to based on the build setting you did:
1 - OpenSSL libraries
2 - Boost python
3 - libtorrent libraries
There is an optional file that mentioned in some forums and discussion msvcr90.dll which does not effect on my project but good to point.
Put those files to a directory which can be find by python interpreter or put in project your folder and add this piece of code before imporing libtorrent :
import os
current_path = os.path.abspath(".")
# do not pass relative path like ".", pass full path
os.add_dll_directory(current_path)
Sorry for any poor english. :)
I want to compile a program where I need to build boost library with static linkage, since in Visual Studio 2017 Community I get the following linker error:
LINK : fatal error LNK1104: File "libboost_filesystem-vc140-mt-gd-1_63.lib" could not be opened.
I compiled that already long ago with a different VS version, where it worked.
So, I tried to compile boost 1.63 as discribed on their page. In the VS command prompt, I adopted the arguments from this answer (but just b2 without arguments doesn't work either):
bootstrap
b2 -j8 toolset=msvc-14.1 address-model=32 architecture=x86 link=static threading=multi runtime-link=shared --build-type=complete stage
After the call to b2 I get the following error message in the command window:
C:/Program Files/boost_1_63_0/tools/build/src/tools\msvc.jam:834: in generate-se
tup-cmd
*** argument error
* rule maybe-rewrite-setup ( toolset : setup-script : setup-options : version :
rewrite-setup ? )
* called with: ( msvc : : : default : )
* missing argument setup-script
C:/Program Files/boost_1_63_0/tools/build/src/tools\msvc.jam:746:see definition
of rule 'maybe-rewrite-setup' being called
C:/Program Files/boost_1_63_0/tools/build/src/tools\msvc.jam:1076: in configure-
really
C:/Program Files/boost_1_63_0/tools/build/src/tools\msvc.jam:201: in configure
C:/Program Files/boost_1_63_0/tools/build/src/tools\msvc.jam:153: in msvc.init
C:/Program Files/boost_1_63_0/tools/build/src/build\toolset.jam:43: in toolset.u
sing
C:/Program Files/boost_1_63_0/tools/build/src/build\project.jam:1052: in using
project-config.jam:3: in modules.load
C:/Program Files/boost_1_63_0/tools/build/src\build-system.jam:249: in load-conf
ig
C:/Program Files/boost_1_63_0/tools/build/src\build-system.jam:412: in load-conf
iguration-files
C:/Program Files/boost_1_63_0/tools/build/src\build-system.jam:524: in load
C:\Program Files\boost_1_63_0\tools\build\src/kernel\modules.jam:295: in import
C:\Program Files\boost_1_63_0\tools\build\src/kernel/bootstrap.jam:139: in boost
-build
C:\Program Files\boost_1_63_0\boost-build.jam:17: in module scope
Question: What is the problem here? How can I build the required libs?
I am building GDAL from source using the MSVC 2015 64-bit command prompt. I am using Windows 8. Part way through the build, I get the following error:
Creating library gdal_i.lib and object gdal_i.exp
odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol _vsnwprintf_s referenced in function StringCchPrintfW
gdal201.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\link.EXE"' : return code '0x460'
Stop.
I have read on the Microsoft Site and GDAL Git issues section that this was a problem with the 2014 MSVC and pre-release version of MSVC 2015, but the issue was supposed to be resolved prior to the final release of MSVC 2015.
https://github.com/mapbox/windows-builds/issues/53
https://connect.microsoft.com/VisualStudio/feedback/details/1134693/vs-2015-ctp-5-c-vsnwprintf-s-and-other-functions-are-not-exported-in-appcrt140-dll-breaking-linkage-of-static-libraries
I don't seem to be the only person with this issue, but I am also not seeing a solution (besides reverting to an older version of MSVC such as 2013). Has anybody had any luck getting GDAL to build using MSVC 2015 (64 bit)?
GDAL-2.1.0 already has a similar change on nmake.opt
!IFDEF ODBC_SUPPORTED
!IF $(MSVC_VER) >= 1900
# legacy_stdio_definitions.lib : https://connect.microsoft.com/VisualStudio/feedback/details/1134693/vs-2015-ctp-5-c-vsnwprintf-s-and-other-functions-are-not-exported-in-appcrt140-dll-breaking-linkage-of-static-libraries
ODBCLIB = legacy_stdio_definitions.lib odbc32.lib odbccp32.lib user32.lib
!ELSE
ODBCLIB = odbc32.lib odbccp32.lib user32.lib
!ENDIF
!ENDIF
but you must also specify the Visual Studio version from the command line with parameter MSVC_VER.
e.g. for Visual Studio 2015 (MSVC_VER==1900) use this command line to compile
nmake -f makefile.vc MSVC_VER=1900
I edited nmake.opt:
I replaced line 667 ... :
!IFDEF ODBC_SUPPORTED
ODBCLIB = odbc32.lib odbccp32.lib user32.lib
!ENDIF
with:
!IFDEF ODBC_SUPPORTED
!IF $(MSVC_VER) < 1900
ODBCLIB = odbc32.lib odbccp32.lib user32.lib
!ELSE
ODBCLIB = legacy_stdio_definitions.lib odbc32.lib odbccp32.lib user32.lib
!ENDIF
!ENDIF
/Anders
In addition to the above, I also had to make the following modification to the nmake.opt file:
the line that says
!IFNDEF MSVC_VER
#assume msvc VS2008.
MSVC_VER=1500
!ENDIF
Should be changed to:
!IFNDEF MSVC_VER
#assume msvc VS2015.
MSVC_VER=1900
!ENDIF
I'm trying to get the boost-python extension module tutorial working on a modern C++14 compiler in Windows 10. I've downloaded the latest versions of boost 1.57 and python 3.5a source using vc-14 (VS 2015 CTP 5).
I compiled python from source using VS 2015 CTP 5 and these instructions: 1.1.3.3. Windows.
I've run the command
.\bootstrap.bat && .\b2 stage toolset=msvc --with-python
from the boost project folder c:\boost
This is the user-config.jam file in my home directory:
using msvc : 14.0 : C:\\Program\ Files\ (x86)\\Microsoft\ Visual\ Studio\ 14.0\\VC\\bin\\cl.exe ;
using python
: 3.5 # Version
: C:\\python35a3\\PCBuild\\win32\\python.exe # Python Path
: C:\\python35a3\\include # include path
: C:\\python35a3\\libs # lib path
: <define>BOOST_ALL_NO_LIB=1
;
Running bjam in the tutorial directory results in an incompatibility when creating the pdb file:
c:\boost\libs\python\example\tutorial>bjam --debug-configuration
notice: found boost-build.jam at C:/boost/libs/python/example/tutorial/boost-build.jam
notice: loading Boost.Build from C:/boost/tools/build/src
....
notice: Loading user-config configuration file 'user-config.jam' from 'C:/Users/marcel'.
notice: [msvc-cfg] msvc-14.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe'
notice: [msvc-cfg] msvc-12.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\cl.exe'
notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe' 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-14.0
notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>/<address-model>', setup: 'call "C:\Users\marcel\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul
'
notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>/<address-model>32', setup: 'call "C:\Users\marcel\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul
'
notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>x86/<address-model>', setup: 'call "C:\Users\marcel\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul
'
notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>x86/<address-model>32', setup: 'call "C:\Users\marcel\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul
'
notice: [python-cfg] Configuring python...
notice: [python-cfg] user-specified version: "3.5"
notice: [python-cfg] user-specified cmd-or-prefix: "C:\python35a3\PCBuild\amd64\python_d.exe"
notice: [python-cfg] user-specified includes: "C:\python35a3\include"
notice: [python-cfg] user-specified libraries: "C:\python35a3\libs"
notice: [python-cfg] user-specified condition: "<define>BOOST_ALL_NO_LIB=1"
notice: [python-cfg] Checking interpreter command "C:\python35a3\PCBuild\amd64\python_d.exe"...
notice: [python-cfg] running command 'DIR /-C /A:S "C:\Python35a3\PCbuild\amd64\python_d.exe" 2>&1'
notice: [python-cfg] running command 'C:\python35a3\PCBuild\amd64\python_d.exe -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: "C:\python35a3\PCBuild\amd64\python_d.exe"
notice: [python-cfg] include path: "C:\python35a3\include"
notice: [python-cfg] library path: "C:\python35a3\libs"
notice: [python-cfg] DLL search path: "C:\python35a3"
notice: Searching '../../../..' for project-config configuration file 'project-config.jam'.
notice: Loading project-config configuration file 'project-config.jam' from '../../../..'.
....
...patience...
...patience...
...found 1893 targets...
...updating 6 targets...
msvc.link.dll bin\msvc-14.0\debug\threading-multi\hello_ext.dll
Creating library bin\msvc-14.0\debug\threading-multi\hello_ext.pdb and object bin\msvc-14.0\debug\threading-multi\hello_ext.exp
LINK : fatal error LNK1207: incompatible PDB format in 'c:\boost\libs\python\example\tutorial\bin\msvc-14.0\debug\threading-multi\hello_ext.pdb'; delete and rebuild
....
...removing bin\hello.test\msvc-14.0\debug\threading-multi\hello.py
...skipped <pbin\hello.test\msvc-14.0\debug\threading-multi>hello for lack of <pbin\hello.test\msvc-14.0\debug\threading-multi>hello.py...
...failed updating 3 targets...
...skipped 3 targets...
The command producing the error output is:
call "C:\Users\marcel\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul
link /NOLOGO /INCREMENTAL:NO /DLL /NOENTRY /DEBUG /MACHINE:X86 /MANIFEST /subsystem:console /out:"bin\msvc-14.0\debug\threading-multi\hello_ext.dll" /IMPLIB:"bin\msvc-14.0\debug\threading-multi\hello_ext.pdb" /LIBPATH:"C:\python35a3\libs" #"bin\msvc-14.0\debug\threading-multi\hello_ext.dll.rsp"
Creating library bin\msvc-14.0\debug\threading-multi\hello_ext.pdb and object bin\msvc-14.0\debug\threading-multi\hello_ext.exp
LINK : fatal error LNK1207: incompatible PDB format in 'c:\boost\libs\python\example\tutorial\bin\msvc-14.0\debug\threading-multi\hello_ext.pdb'; delete and rebuild
The link command seems to be consistent with the way python and boost are compiled (32 bit on the same compiler version).
Is there an way to diagnose where this error originated?
UPDATE: Compiling with VC9 (VS2010) and a prebuilt python 3.4 installation. I still get the same error:
link /NOLOGO /INCREMENTAL:NO /DLL /NOENTRY /DEBUG /MACHINE:X86 /MANIFEST /subsystem:console /out:"bin\msvc-10.0\debug\threading-multi\hello_ext.pyd" /IMPLIB:"bin\msvc-10.0\debug\threading-multi\hello_ext.pdb" /LIBPATH:"C:\python34\libs" #"bin\msvc-10.0\debug\threading-multi\hello_ext.pyd.rsp"
Creating library bin\msvc-10.0\debug\threading-multi\hello_ext.pdb and object bin\msvc-10.0\debug\threading-multi\hello_ext.exp
LINK : fatal error LNK1207: incompatible PDB format in 'c:\boost\libs\python\example\tutorial\bin\msvc-10.0\debug\threading-multi\hello_ext.pdb'; delete and rebuild
Running the python interpreter to confirm the correct compiler version:
c:\Python34\python.exe
Python 3.4.2 (v3.4.2:ab2c023a9432, Oct 6 2014, 22:15:05) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
Apparently this error has nothing to do with the "bleeding edge-ness" of the environment the build is running on. Rather its a direct result of a boost-build configuration issue.
UPDATE 2: Trying the same test with pre-built Python 2.7 and VS 2008 results in the same error.
UPDATE 3 SOLVED This builds correctly on boost v1.55 when the following steps are taken:
Download and build python 3.5 a3 and build boost 1.55 with VC14 by
modifying the user-config.jam file in the home directory and running
"bjam stage --use-python"
Move the resultant files in stage\lib from
libboost* to boost* run bjam from the tutorial directory
Change the errant link command by adding the following LIBPATH switch:
/LIBPATH:c:\boost_1_55_0\stage\lib
The problem of linking to python 3.5 alpha3 with VC14 is isolated to boost v1.57 builds.
The problem seems to have been introduced with 1.56. I've managed to get Boost.Build working again by editing the file:
D:\boost\boost_1_59_0\tools\build\src\tools\msvc.jam
I made two changes:
Change this (lines #1351-1355):
generators.register [ new msvc-linking-generator msvc.link.dll :
OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB IMPORT_LIB :
<toolset>msvc <suppress-import-lib>false ] ;
generators.register [ new msvc-linking-generator msvc.link.dll :
OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB :
<toolset>msvc <suppress-import-lib>true ] ;
to:
generators.register [ new msvc-linking-generator msvc.link.dll :
OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB IMPORT_LIB :
<toolset>msvc ] ;
Remove this line (#1472):
toolset.flags msvc.link.dll LINKFLAGS <suppress-import-lib>true : /NOENTRY ;
I've tested this on Win7 with VS2012 and Python 2.7.
Yes, I think Boost.Build 1.59 (and possibly 1.57 and 1.58) is broken on Windows. I gave up using Boost.Build and built it myself.
I'm trying to build Boost 1.49.0 using MSVC2010 and it fails with the following error:
file bin.v2\libs\math\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\assoc_laguerre.obj.rsp
"libs\math\build\..\src\tr1\assoc_laguerre.cpp"
-Fo"bin.v2\libs\math\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\assoc_laguerre.obj"
-Yu"pch.hpp"
-Fp"bin.v2\libs\math\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\pch.pch"
-TP
/O2
/Ob2
/W3
/GR
/MT
/Zc:forScope
/Zc:wchar_t
/wd4675
/EHs
-c
-DBOOST_ALL_NO_LIB=1
-DBOOST_BUILD_PCH_ENABLED
-DNDEBUG
"-I."
"-Ilibs\math\src\tr1"
compile-c-c++ bin.v2\libs\math\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\assoc_laguerre.obj
call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul
cl /Zm800 -nologo #"bin.v2\libs\math\build\msvc-10.0\release\link-static\runtime-link-static\threading-multi\assoc_laguerre.obj.rsp"
assoc_laguerre.cpp
c1xx : fatal error C1027: Inconsistent values for /Ym between creation and use of precompiled header
That is the first instance of that error, my log file has 995 instances of the same error before the build aborts.
The contents of project-config.jam are:
import option ;
using msvc ;
option.set keep-going : false ;
using python : 3.2 : C:\\Tools\\Python\\3.2.2 ;
And the build command I used is:
b2 --toolset=msvc-10.0 --build-type=complete stage -q -d+2 -sICU_PATH="C:\Tools\ICU\4.8.1.1"
Any idea what's causing this?
Here is an explanation of the error, and here is someone who had this problem when building something else and his solution.
He modified his /Zm parameter from /Zm1000 to /Zm500 (you have /Zm800). I don't know if changing it to the same value will help you, but you can try playing with it (this compiler's flag explanation can be found here).
You can use the cxxflags command line argument to modify the compiler flags (taken from here).