## Installation and compatibility

### Supported compilers and platforms

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++ 13.1.0.146 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 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. This problem is fixed in GCC 5.1 and newer. For this reason LTO is not supported in Boost.Log until GCC version 5.1.

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.