Building Boost 1.64, 1.65, 1.66 with Visual Studio 2017
Visual Studio 2017 has been released, and it wasn’t exactly trivial to get previous versions of boost (1.63 and down) or next versions 1.67 and 1.68 to build with it.
There were a multitude of difficulties, but the two main problems are:
- find the installation directory of VS2017, and
- boost build scripts are strictly tied to versions of compilers.
Unless a boost release doesn’t support a particular version of Visual Studio, it isn’t very easy to build boost with it.
Boost 1.64 was released 20th of April 2017 and can be downloaded from http://www.boost.org/users/history/version_1_64_0.html.
New in Boost 1.64 is a library called Boost.Process. It has been in development since 2006 and provides a cross platform way of spawning child processes and communication through synchronous or asynchronous streams.
Building Boost 1.64 with Visual Studio 2017
For the impatient, scripts are available at Github: https://github.com/Studiofreya/boost-build-scripts.
Boost 1.64 is the first Boost release after Visual Studio 2017 was released 7th of March 2017. This time they haven’t slapped 2017 over 2015. Microsoft have redone the installer, the (internal) location of the tools and it is possible to have multiple versions of Visual Studio 2017 installed, each with their own set of available tools.
- Download and extract the Boost archive from http://www.boost.org/users/history/version_1_64_0.html.
- Create a file named
build_boost_1_64_vs2017.batin the same folder asboost_1_64_0with the following contents:
@echo off rem Directory to boost root set boost_dir=boost_1_64_0 rem Number of cores to use when building boost set cores=%NUMBER_OF_PROCESSORS% rem What toolset to use when building boost. rem Visual Studio 2012 -> set msvcver=msvc-11.0 rem Visual Studio 2013 -> set msvcver=msvc-12.0 rem Visual Studio 2015 -> set msvcver=msvc-14.0 rem Visual Studio 2017 -> set msvcver=msvc-14.1 set msvcver=msvc-14.1 rem Start building boost echo Building %boost_dir% with %cores% cores using toolset %msvcver%. cd %boost_dir% call bootstrap.bat rem Most libraries can be static libs b2 -j%cores% toolset=%msvcver% address-model=64 architecture=x86 link=static threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/x64 b2 -j%cores% toolset=%msvcver% address-model=32 architecture=x86 link=static threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/win32 b2 -j%cores% toolset=%msvcver% address-model=64 architecture=x86 link=shared threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/x64 b2 -j%cores% toolset=%msvcver% address-model=32 architecture=x86 link=shared threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/win32 pause
This script has been tested with a clean install of Windows 10 and a minimal install of Visual Studio 2017 with C++.
Building Boost 1.65, 1.66 in Visual Studio 2017
The process is mostly the same as with 1.64. If you are having problems and getting errors like “Unknown compiler version…” or “Failed to build Boost.Build engine…”, please, see our comment section.
The latest update to Visual Studio 2017 (15.5) may create some issues with existing code. See Visual Studio 2017 with C++17 and Boost for more details.
Older versions of Visual Studio
This bat file can be adjusted to build Boost 1.64 with Visual Studio 2012, 2013, 2015 and 2017 by adjusting the msvcver variable.
- Visual Studio 2012 ->
set msvcver=msvc-11.0 - Visual Studio 2013 ->
set msvcver=msvc-12.0 - Visual Studio 2015 ->
set msvcver=msvc-14.0 - Visual Studio 2017 ->
set msvcver=msvc-14.1
Using Boost in Visual Studio 2017
Guide on how to use Boost 1.64 in VS2017 or any of the previous versions of Visual Studio.
Use the comment section if there are any questions.
Related posts:
Comments
Leave a Reply
*
Using the scripts as-is from the repo, it appears to be building the shared versions of the .libs instead of the static versions, even though static is specified. I end up with filenames such as libboost_atomic-vc141-mt-gd-1_64.lib instead of libboost_atomic-vc141-mt-sgd-1_64.lib, and further inspection reveals that it is definitely the shared version, not just incorrect filenames.
Hi Jeremy,
There are two kinds of static (and two kinds of dynamic) libraries.
From http://www.boost.org/doc/libs/1_64_0/more/getting_started/windows.html#library-naming the “s” in “sgd” is static runtime linking.
Change
runtime-link=sharedtoruntime-link=staticto build static libraries with a static runtime. Static runtime linking is similar to the /MT compiler flag, and dynamic runtime linking is similar to the /MD compiler flag.For more details have a look at https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
The runtime-link must have the same settings as the rest of the application you’re developing.
The other kind of dynamic library is the DLL version.
Kent
Hi, thanks for the article and the work you did to find this. I tried this with boost 1.65 (changing the version names in the batch script accordingly) and I still see lots of “Unknown compiler version – please run the configure tests and report the results” warnings. Do you see these following your instructions?
Actually, it appears the below checkin fixes the “unknown compiler” issues. Thanks once again.
https://github.com/boostorg/config/commit/a0147b73e8bde8f4b2c19c96166353dba8fa9914
Hi, no problem!
Visual Studio 2017 Update 3 bumped the internal compiler version, therefore triggering the message. Update 3 got released 14th of August, while Boost 1.65 was released 21th of August. While the fix is apparently easy, there was some other issue as well according to the mailing list: https://lists.boost.org/Archives/boost/2017/08/238149.php
It seems Boost 1.65.1 will be released in a couple of days, maybe it’ll be corrected there.
I am getting error building Boost 1-65-1 for VS 2017 (15.3.3). Any idea why?
==========================================================
My cmd window shows this:
Building boost_1_65_1 with 8 cores using toolset msvc-14.1.
Building Boost.Build engine
Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.
You can try to obtain a prebuilt binary from
http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.
‘b2’ is not recognized as an internal or external command,
operable program or batch file.
‘b2’ is not recognized as an internal or external command,
operable program or batch file.
Press any key to continue . . .
===================================================
My Boost log file shows this….
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.0.26730.12
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: ‘x86’
###
### Using ‘vc141’ toolset.
###
C:\Users\Valued Customer\source>if exist bootstrap rd /S /Q bootstrap
C:\Users\Valued Customer\source>md bootstrap
C:\Users\Valued Customer\source>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\yyacc0 yyacc.c
yyacc.c
c1: fatal error C1083: Cannot open source file: ‘yyacc.c’: No such file or directory
=========================================================
Hi Matt,
I’ve seen that error before. Some colleagues had it. I think it boiled down to the VS2017 environment. Try installing the “Windows 10 SDK” component in the VS2017/C++ setup. This applies even if you don’t have Win10 as operating system.
Kent
Thanks. I tried to install Windows 10 SDK and got this. Still, I tried to run the boost install script and got the same error…
I did google and installed the latest Windows sdk desperately and boost still did not install.
I am using Windows 7.
==========================================================
Something went wrong with the install.
You can troubleshoot the package failures by:
1. Search for solutions using the search URL below for each package failure
2. Modify your selections for the affected workloads or components and then retry the installation
3. Remove the product from your machine and then install again
If the issue has already been reported on the Developer Community, you can find solutions or workarounds there. If the issue has not been reported, we encourage you to create a new issue so that other developers will be able to find solutions or workarounds. You can create a new issue from within the Visual Studio Installer in the upper-right hand corner using the “Provide feedback” button.
================================================================================
Package ‘Win10SDK_Hidden_10.0.10240_2,version=10.0.10240.117’ failed to install.
Search URL
https://aka.ms/VSSetupErrorReports?q=PackageId=Win10SDK_Hidden_10.0.10240_2;PackageAction=Install;ReturnCode=1001
Details
Command executed: “c:\windows\syswow64\\windowspowershell\v1.0\powershell.exe” -NonInteractive -NoLogo -NoProfile -ExecutionPolicy Bypass -InputFormat None “$ErrorActionPreference=”””Stop”””; $VerbosePreference=”””Continue”””; $CeipSetting=”””on”””; $ScriptPath=”””C:\ProgramData\Microsoft\VisualStudio\Packages\Win10SDK_Hidden_10.0.10240_2,version=10.0.10240.117\WinSdkInstall.ps1″””; $SetupExe=”””sdksetup.exe”””; $SetupLogFolder=”””standalonesdk”””; $PackageId=”””Win10SDK_Hidden_10.0.10240_2″””; $LogFile=”””C:\Users\Valued Customer\AppData\Local\Temp\dd_setup_20170912063350_001_Win10SDK_Hidden_10.0.10240_2.log”””; $SetupParameters=”””/features OptionId.AvrfExternal OptionId.WindowsSoftwareDevelopmentKit OptionId.WindowsSoftwareLogoToolkit /quiet /norestart”””; $PayloadsNotYetDownloaded=1; (gc $ScriptPath | out-string) | Invoke-Expression; if (!$?) { exit 1603 } elseif ($LastExitCode) { exit $LastExitCode }”
Return code: 1001
Return code details: Recursion too deep; the stack overflowed.
Log
C:\Users\Valued Customer\AppData\Local\Temp\dd_setup_20170912063350_001_Win10SDK_Hidden_10.0.10240_2.log
Impacted workloads
Desktop development with C++ (Microsoft.VisualStudio.Workload.NativeDesktop,version=15.0.26606.0)
Impacted components
Windows 10 SDK (10.0.10240.0) (Microsoft.VisualStudio.Component.Windows10SDK.10240,version=15.0.26208.0)
I finally got it to Build: I usually click the *.bat file and it runs. This time, I had to use “x64 Native Tools Command Prompt for VS 2017” on *.bat file. Shoo! Any idea why cmd.exe worked in the past and now but now it does not? Thanks.
As ever, thanks for this. My project is /Mtd & /MT so I used to do this:
b2 -j%cores% toolset=%msvcver% address-model=64 architecture=x86 link=static threading=multi runtime-link=static –build-type=complete stage –stagedir=stage/x64
b2 -j%cores% toolset=%msvcver% address-model=32 architecture=x86 link=static threading=multi runtime-link=static –build-type=complete stage –stagedir=stage/win32
This built static libraries for both x86 & x64.
But this time x64 is not building completely (23 builds), x86 is (74 builds).
I use x64 Native Tools Command Propt for VS2017, point to *.bat file, run it.
Know what’s going on?
Hi again Matt!
Is this a newly unzipped boost package, or have something been reused?
Could it be that the targets have been previously built?
Are there any older versions laying around?
Kent
Thanks for response..
I deleted the boost 1 66 directory (and all of int’s contents). I then downloaded a new zip from c++boost and ran it. 27 Builds in x64 and 74 in x86.
Yes. I have a directories called ../Libraries/boost_1_64_0, boost_1_65_1, boost_1_66_0, BUILD_BOOST_1_6*.bat. (one *.bat per boost c++ build)
I see in the beginning of boost build when writing to console for the x64 builds:
Performing Configuration Checks:
32-bit
..
..
..
..
x86
Shouldn’t one of those say x64? I am using x64 Native Tools Command Prompt for VS2017 but it does not appear to using x64 properly.
This was my error (January 12, 2018): ‘bin.v2\libs\program_options\build\msvc-14.1\debug\address-model-64\link-static\runtime-link-static\threadapi-win32\threading-multi\libboost_program_options-vc141-mt-sgd-x64-1_66.lib.rsp’!
Here is the solution:
Add –abbreviate-paths to b2
Go figure?!?