The Boost initiative is the next hottest thing after STL for the C++ community. While the documentation is quite good, it can be overwhelming to get a quick start. This simple article explains a method of building Boost libraries. I wrote it because many questions in the newsgroups are about linker errors, which happen if you try to link against some of the Boost libraries. The original article was written with Boost version 1.33, but the updated version works only with the new Bjam syntax which was introduced with version 1.34. The build scripts work up to version 1.57.
While most of the Boost libraries are template-based (i.e. header only), some of them - e.g. date-time, regex, filesystem, signals - come with cpp source files and thus require a library to be generated. Boost uses a build system called Bjam, which can be configured for a lot of platforms. I work only on Windows with Visual Studio, so I'll describe here a configuration for these combination for Visual Studio 2003, 2008, 2010 and 2013.
After downloading the Boost libraries and unpacking them in a folder - referenced in this article with <boost_root>, e.g. on my PC it is C:\work sdk\boost, the libraries need to be built:
- Build Bjam
- Build the Boost libraries
Bjam can be built in two ways:
- Use the 'bootstrap.bat' batch file located in <boost_root>. Run this batch file and Bjam will be automatically built and added to the root. As of boost 1.71 bjam.exe is not copied anymore. Use b2.exe instead.
- Build Bjam 'manually': browse to <boost_root>\tools\build\jam_src and run build.bat from a command prompt. This will start to build Bjam, which ends up in <boost_root>\tools\build\jam_src\bin.ntx86\bjam.exe. Copy this file to the root of Boost, <boost_root>. The folder has been changed since then for the current version (boost 1.71) <boost_root>\tools\build\src\engine
Building Boost Libraries
The Bjam system must be told that you want to build debug/release libraries, build with threading in mind, build static or dynamic library and link against various options of the STL or platforms. I only use Visual Studio with Plauger's STL and choose for the following configuarion
- Build a debug build with multithreading and dynamic linking.
- Build a release build with multithreading and dynamic linking.
With the release of Visual Studio 2005 / 2008, Microsoft supports side by side installations of the crt. With manifests, one can bind a module to a specific version of the crt. The Boost libraries are dependent on the crt as well, and you can instruct the build process to use the latest version through a '
Note: the command lines use bjam.exe here but b2.exe would work as well.
This leads to the following options for Visual Studio 2003:
- bjam toolset=msvc-7.1 variant=debug threading=multi link=shared
- bjam toolset=msvc-7.1 variant=release threading=multi link=shared
For Visual Studio 2008:
- bjam toolset=msvc-9.0 variant=debug threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
- bjam toolset=msvc-9.0 variant=release threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
For Visual Studio 2010:
- bjam toolset=msvc-10.0 variant=debug threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
- bjam toolset=msvc-10.0 variant=release threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
For Visual Studio 2013:
- bjam toolset=msvc-12.0 variant=debug threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
- bjam toolset=msvc-12.0 variant=release threading=multi link=shared define=_BIND_TO_CURRENT_VCLIBS_VERSION
I've already made eight batch files with the same command(s). Be aware that these are zip files since codeproject didn't allow *.bat files to be uploaded:
Unzip and copy the batch files to the root of Boost, <boost_root>. Now the libraries can be built:
- Open the command prompt.
- Run vcvars32.bat from your favourite Visual Studio version.
- Run the batch files, e.g. zbuilddebug_vc71.bat.
Bjam will now try to build the libraries.
For the stressful software engineer, I offer here batch files which will do it all together: they build bjam if it does not exist and build the debug and release mode libraries in one go:
After the build process has finished, the library executables are created in the <boost_root>\bin.v2 directory, e.g.:
- boost_date_time-vc120-mt-gd-1_57.dll for the multithreaded debug build of a date-time library.
- boost_date_time-vc120-mt-1_57.dll for the multithreaded release build of a date-time library.
Because all of these files are built under their own library names, one can copy them all - i.e. search on 'mt-gd-1_57 and mt-1_57 - to one location and adjust Visual Studio to point to this library location. Alternatively one can use the <boost_root>\stage directory. However this directory does not contain the associated PDBs, which is unhandy during debugging.
Using Boost Libraries
We have built the shared libraries and therefore we have to instruct Visual Studio to link against them. Fortunately, Boost has incorporated an "autolink" feature. Thus, with the preprocessor one can link to the correct libraries. Define the following preprocessor statements:
Even better, include a header file in your precompiled header before including a Boost header:
Room for Improvement
- For some reason, the "normal," i.e. non-dynamic, libraries get built.
- Python library should also get built, but for some reason it gets excluded.
- Visual Studio 2005 introduces the safe C and iterator concepts. Boost libraries don't like them and should be turned off.
- Precompiled header specification. Without it takes half an hour to build the libraries
- 11 September, 2005 - Original version posted
- 18 July, 2007 - Updated with Boost 1.34 syntax
- 25 November 2009 - Updated with manifests and the 'all' batch file; removed old syntax
- 27 August 2013 - Updated for VS2010, VS2013
- 05 Septemeber 2017- b2
- Leon Wiertz: tip about manifests and the 'all' batch file