From d91afdd63285a2120b0e19ec440cb286282d7aef Mon Sep 17 00:00:00 2001 From: Egor Tensin Date: Tue, 31 Jan 2017 02:22:42 +0300 Subject: boost: update --- _posts/2017-01-07-building-boost.md | 64 ++++++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 25 deletions(-) (limited to '_posts') diff --git a/_posts/2017-01-07-building-boost.md b/_posts/2017-01-07-building-boost.md index 193b786..5e71334 100644 --- a/_posts/2017-01-07-building-boost.md +++ b/_posts/2017-01-07-building-boost.md @@ -3,23 +3,35 @@ title: Building Boost on Windows layout: post excerpt: > This post describes the process of building Boost on Windows using either - Visual Studio or the combination of Cygwin & MinGW-w64. + Visual Studio or the combination of Cygwin + MinGW-w64. +custom_css: + - code-nowrap.css --- Below you can find the steps required to build Boost libraries on Windows. These steps tightly fit my typical workflow, which is to use Boost libraries in -CMake builds using either Visual Studio or the combination of Cygwin & +CMake builds using either Visual Studio or the combination of Cygwin + MinGW-w64. I would expect, however, that the procedure for the latter toolset can easily be adjusted for generic GCC distributions (including vanilla GCCs found in popular Linux distributions). -One of the features of this workflow is that I build throwaway, "run once on -each VM, record the results, and scrap it" executables not more often than not, -so I prefer to link everything statically, including for instance the C/C++ +One of the features of this workflow is that I build throwaway, "run +everywhere, record the results, and scrap it" executables more often than not, +so I prefer to link everything statically, including, for instance, C/C++ runtimes. This is implemented by passing `runtime-link=static` to Boost's build utility `b2`; change this to `runtime-link=dynamic` to link the runtime dynamically. +Excerpts from shell sessions in this post feature a few different commands +besides Boost's `b2` and `cmake`, like `cd` and `cat`. +They are used to hint at my personal directory layout, display various +auxiliary files, etc. +Windows' `cd`, for example, simply prints current working directory; Cygwin's +`pwd` serves the same purpose. +`cat` is used to display files. +Windows' command prompts are denoted with `>`s at beginning of each line; +Cygwin's — with `$`s. + Visual Studio ------------- @@ -50,7 +62,7 @@ D:\workspace\third-party\boost_1_61_0\msvc ### x64 The only important difference is that you have to pass `address-model=64` to -`b2` (notice also the different "stage" directory). +`b2` (notice also the different "staging" directory). ``` > cd @@ -78,27 +90,29 @@ It is required to avoid file name clashes; unlike the Visual Studio "toolset" whether the debug or the release version of a library was built) in file names. Also, linking the runtime statically doesn't really make sense for MinGW, as it -always links to msvcrt.dll, which is [simply Visual Studio 6.0 runtime]. +always links to msvcrt.dll, which is [simply the Visual Studio 6.0 runtime]. -[simply Visual Studio 6.0 runtime]: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ +[simply the Visual Studio 6.0 runtime]: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ In the examples below, only the debug versions of the libraries are built. Build the release versions by executing the same command, and substituting -`variant=release` and the proper "stage" directory path. +`variant=release` instead of `variant=debug` and either +`--stagedir=stage/x86/release` or `--stagedir=stage/x64/release`, depending +on the target architecture. ### x86 ``` -> cd +$ pwd /cygdrive/d/workspace/third-party/boost_1_61_0/mingw -> ./bootstrap.sh +$ ./bootstrap.sh ... -> cat user-config-x86.jam +$ cat user-config-x86.jam using gcc : : i686-w64-mingw32-g++ ; -> ./b2 toolset=gcc-mingw \ +$ ./b2 toolset=gcc-mingw \ target-os=windows \ link=static \ variant=debug \ @@ -114,24 +128,24 @@ using gcc : : i686-w64-mingw32-g++ ; Notice the two major differences from the x86 example: -* `b2 address-model=64 ...` (as in the example for Visual Studio), -* the different user configuration file, pointing to `x86_64-w64-mingw32-g++` +* the addition of `address-model=64` (as in the example for Visual Studio), +* a different "user" configuration file, pointing to `x86_64-w64-mingw32-g++` instead of `i686-w64-mingw32-g++`. -Again, as in the example for Visual Studio, a different "stage" directory needs -to be specified using the `--stagedir` parameter. +Again, as in the example for Visual Studio, a different "staging" directory +needs to be specified using the `--stagedir` parameter. ``` -> cd +$ cd /cygdrive/d/workspace/third-party/boost_1_61_0/mingw -> ./bootstrap.sh +$ ./bootstrap.sh ... -> cat user-config-x64.jam +$ cat user-config-x64.jam using gcc : : x86_64-w64-mingw32-g++ ; -> ./b2 toolset=gcc-mingw \ +$ ./b2 toolset=gcc-mingw \ address-model=64 \ target-os=windows \ link=static \ @@ -190,10 +204,10 @@ You may also want to adjust the paths. #### x86 ``` -> cd +$ pwd /cygdrive/d/workspace/build/test_project/mingw/x86/debug -> cmake -G "Unix Makefiles" \ +$ cmake -G "Unix Makefiles" \ -D CMAKE_BUILD_TYPE=Debug \ -D CMAKE_C_COMPILER=i686-w64-mingw32-gcc \ -D CMAKE_CXX_COMPILER=i686-w64-mingw32-g++ \ @@ -206,10 +220,10 @@ You may also want to adjust the paths. #### x64 ``` -> cd +$ pwd /cygdrive/d/workspace/build/test_project/mingw/x64/debug -> cmake -G "Unix Makefiles" \ +$ cmake -G "Unix Makefiles" \ -D CMAKE_BUILD_TYPE=Debug \ -D CMAKE_C_COMPILER=x86_64-w64-mingw32-gcc \ -D CMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++ \ -- cgit v1.2.3