diff options
| author | Egor Tensin <Egor.Tensin@gmail.com> | 2016-12-30 04:04:49 +0300 |
|---|---|---|
| committer | Egor Tensin <Egor.Tensin@gmail.com> | 2016-12-30 04:04:49 +0300 |
| commit | e46cb42ce923f2c4e1fb14f91028b8f239ed4286 (patch) | |
| tree | c651a24d83ce6948f1f240e27b711172d315b5b1 | |
| parent | bash.md: how to declare arrays (diff) | |
| download | notes-e46cb42ce923f2c4e1fb14f91028b8f239ed4286.tar.gz notes-e46cb42ce923f2c4e1fb14f91028b8f239ed4286.zip | |
boost.md: update
| -rw-r--r-- | boost.md | 163 |
1 files changed, 108 insertions, 55 deletions
@@ -1,88 +1,141 @@ Boost ===== +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 & +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++ +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. + Visual Studio ------------- -### x86 +Statically-linked Boost libraries are built by default, both the debug and the +release versions of them. +While it is required to keep x86/x64 libraries in different directories (to +avoid file name clashes), it's not necessary to separate debug libraries from +their release counterparts, because that information is actually encoded in +file names (the "gd" suffix). -From either "x86 Cross Tools Command Prompt" or "x86 Native Tools Command -Prompt": +### x86 - > cd - D:\workspace\third-party\boost_1_61_0\msvc +``` +> cd +D:\workspace\third-party\boost_1_61_0\msvc - > bootstrap - ... +> bootstrap +... - > b2 --stagedir=stage\x86 ^ - --with-filesystem ^ - --with-program_options ^ - ... +> b2 --stagedir=stage\x86 ^ + runtime-link=static ^ + --with-filesystem ^ + --with-program_options ^ ... +... +``` ### x64 -From either "x64 Cross Tools Command Prompt" or "x64 Native Tools Command -Prompt": +The only important difference is that you have to pass `address-model=64` to +`b2` (notice also the different "stage" directory). - > cd - D:\workspace\third-party\boost_1_61_0\msvc +``` +> cd +D:\workspace\third-party\boost_1_61_0\msvc - > bootstrap - ... +> bootstrap +... - > b2 --stagedir=stage\x64 ^ - address-model=64 ^ - --with-filesystem ^ - --with-program_options ^ - ... +> b2 --stagedir=stage\x64 ^ + runtime-link=static ^ + address-model=64 ^ + --with-filesystem ^ + --with-program_options ^ ... +... +``` Cygwin + MinGW-w64 ------------------ +Contrary to the Visual Studio example above, it is required to store debug and +release libraries *as well as* x86 and x64 libraries in different directories. +It is required to avoid file name clashes; unlike the Visual Studio "toolset" +(in Boost's terms), GCC-derived toolsets don't encode any information (like +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]. + +[simply 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. + ### x86 - > cd - /cygdrive/d/workspace/third-party/boost_1_61_0/mingw/x86 +``` +> cd +/cygdrive/d/workspace/third-party/boost_1_61_0/mingw - > ./bootstrap.sh - ... +> ./bootstrap.sh +... - > cat user-config-x86.jam - using gcc : : i686-w64-mingw32-g++.exe ; - - > ./b2 toolset=gcc-mingw \ - target-os=windows \ - link=static \ - variant=debug \ - --stagedir=stage/debug \ - --user-config=user-config-x86.jam \ - --with-filesystem \ - --with-program_options \ - ... +> cat user-config-x86.jam +using gcc : : i686-w64-mingw32-g++ ; + +> ./b2 toolset=gcc-mingw \ + target-os=windows \ + link=static \ + variant=debug \ + --stagedir=stage/x86/debug \ + --user-config=user-config-x86.jam \ + --with-filesystem \ + --with-program_options \ ... +... +``` ### x64 - > cd - /cygdrive/d/workspace/third-party/boost_1_61_0/mingw/x64 +Notice the two major differences from the x86 example: - > ./bootstrap.sh - ... +* `b2 address-model=64 ...` (as in the example for Visual Studio), +* the 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. + +``` +> cd +/cygdrive/d/workspace/third-party/boost_1_61_0/mingw + +> ./bootstrap.sh +... + +> cat user-config-x64.jam +using gcc : : x86_64-w64-mingw32-g++ ; - > cat user-config-x64.jam - using gcc : : x86_64-w64-mingw32-g++.exe ; - - > ./b2 toolset=gcc-mingw \ - target-os=windows \ - address-model=64 \ - link=static \ - variant=debug \ - --stagedir=stage/debug \ - --user-config=user-config-x64.jam \ - --with-filesystem \ - --with-program_options \ - ... +> ./b2 toolset=gcc-mingw \ + address-model=64 \ + target-os=windows \ + link=static \ + variant=debug \ + --stagedir=stage/x64/debug \ + --user-config=user-config-x64.jam \ + --with-filesystem \ + --with-program_options \ ... +... +``` |