Boost C++ Libraries of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards


Installation and compatibility

Supported compilers and platforms
Configuring and building the library

The library should build and work with a reasonably compliant compiler. The library was successfully built and tested on the following platforms:

  • Windows XP, Windows Vista, Windows 7. MSVC 8.0 SP1, MSVC 9.0 and newer.
  • Linux. GCC 4.5 and newer. Older versions may work too, but it was not tested.
  • Linux. Intel C++ Build 20130121.
  • Linux. Clang 3.2 and newer.

The following compilers/platforms are not supported and will likely fail to compile the library:

  • C++11 compilers with non-C++11 standard libraries (like Clang with libstdc++ from GCC 4.2). Please, use a C++11 standard library in C++11 mode.
  • MSVC 8.0 (without SP1) and older.
  • GCC 4.2 and older.
  • Borland C++ 5.5.1 (free version). Newer versions might or might not work.
  • Solaris Studio 12.3 and older.
  • Windows 9x, ME, NT4, 2000 and older are not supported.

Boost.Log should be compatible with all hardware architectures supported by Boost. However, in case of 32 bit x86 architecture the library requires at least i586 class CPU to run.

Notes for GCC users

GCC versions since 4.5 support link time optimization (LTO), when most of optimizations and binary code generation happen at linking stage. This allows to perform more advanced optimizations and produce faster code. Unfortunately, it does not play well with projects containing source files that need to be compiled with different compiler options. Boost.Log is one of such projects, some parts of its sources contain optimizations for modern CPUs and will not run on older CPUs. Enabling LTO for Boost.Log will produce binaries incompatible with older CPUs (GCC bugs 61043, 77845), which will likely result in crashes at run time. For this reason LTO is not supported in Boost.Log.

There is a GCC bug which may cause compilation failures when -march=native command line argument is used. It is recommended to avoid using -march=native argument (or instruction-set=native bjam property) and instead explicitly specify the target CPU (e.g. instruction-set=sandy-bridge).

Notes for MinGW, Cygwin and Visual Studio Express Edition users

In order to compile the library with these compilers special preparations are needed. First, in case of MinGW or Cygwin make sure you have installed the latest GCC version. The library will most likely fail to compile with GCC 3.x.

Second, at some point the library will require a Message Compiler tool (mc.exe), which is not available in MinGW, Cygwin and some versions of MSVC Express Edition. Typically the library build scripts will automatically detect if message compiler is present on the system and disable Event log related portion of the library if it's not. If Event log support is required and it is not found on the system, you have three options to settle the problem. The recommended solution is to obtain the original mc.exe. This tool is available in Windows SDK, which can be downloaded from the Microsoft site freely (for example, here). Also, this tool should be available in Visual Studio 2010 Express Edition. During the compilation, mc.exe should be accessible through one of the directories in your PATH environment variable.

Another way is to attempt to use the windmc.exe tool distributed with MinGW and Cygwin, which is the analogue of the original mc.exe. In order to do that you will have to patch Boost.Build files (in particular, the tools/build/tools/mc.jam file) as described in this ticket. After that you will be able to specify the mc-compiler=windmc option to bjam to build the library.

In case if message compiler detection fails for some reason, you can explicitly disable support for event log backend by defining the BOOST_LOG_WITHOUT_EVENT_LOG configuration macro when building the library. This will remove the need for the message compiler. See this section for more configuration options.

MinGW users on Windows XP may be affected by the bug in msvcrt.dll that is bundled with the operating system. The bug manifests itself as crashes while the library formats log records. This problem is not specific to Boost.Log and may also show in different contexts related to locale and IO-streams management.

Additional notes for Cygwin users

Cygwin support is very preliminary. The default GCC version available in Cygwin (4.5.3 as of this writing) is unable to compile the library because of compiler errors. You will have to build a newer GCC from sources. Even then some Boost.Log functionality is not available. In particular, the socket-based syslog backend is not supported, as it is based on Boost.ASIO, which doesn't compile on this platform. However, the native syslog support is still in place.