The library should build and work with a reasonably compliant compiler. The library was successfully built and tested on the following platforms:
The following compilers/platforms are not supported and will likely fail to compile the library:
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.
GCC versions since 4.5 support link time optimization (LTO), when most of optimizations and binary code generation happens 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 bug), which will likely result in crashes in run time. For this reason GCC 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.
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 (
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
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,
be accessible through one of the directories in your
Another way is to attempt to use the
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
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
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.
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.