Building Boost 1.64 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) 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++.
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 1.64 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