### Configuring and building the library

The library has a separately compiled part which should be built as described in the Getting Started guide. One thing should be noted, though. If your application consists of more than one module (e.g. an exe and one or several dll's) that use Boost.Log, the library must be built as a shared object. If you have a single executable or a single module that works with Boost.Log, you may build the library as a static library.

The library supports a number of configuration macros:

Table 1.1. Configuration macros

Macro name | Effect
--- | ---
`BOOST_LOG_DYN_LINK` | If defined in user code, the library will assume the binary is built as a dynamically loaded library ("dll" or "so"). Otherwise it is assumed that the library is built in static mode. This macro must be either defined or not defined for all translation units of user application that uses logging. This macro can help with auto-linking on platforms that support it.
`BOOST_ALL_DYN_LINK` | Same as `BOOST_LOG_DYN_LINK` but also affects other Boost libraries the same way.
`BOOST_LOG_NO_THREADS` | If defined, disables multithreading support. Affects the compilation of both the library and users' code. The macro is automatically defined if no threading support is detected.
`BOOST_LOG_WITHOUT_CHAR` | If defined, disables support for narrow character logging. Affects the compilation of both the library and users' code.
`BOOST_LOG_WITHOUT_WCHAR_T` | If defined, disables support for wide character logging. Affects the compilation of both the library and users' code.
`BOOST_LOG_NO_QUERY_PERFORMANCE_COUNTER` | This macro is only useful on Windows. It affects the compilation of both the library and users' code. If defined, disables support for the `QueryPerformanceCounter` API in the `timer` attribute. This will result in significantly less accurate time readings. The macro is intended to solve possible problems with earlier revisions of AMD Athlon CPU, described here and here. There are also known chipset hardware failures that may prevent this API from functioning properly (see here).
`BOOST_LOG_USE_NATIVE_SYSLOG` | Affects only the compilation of the library. If for some reason support for the native SysLog API is not detected automatically, define this macro to forcibly enable it
`BOOST_LOG_WITHOUT_DEFAULT_FACTORIES` | Affects only the compilation of the library. If defined, the parsers for settings will be built without any default factories for filters and formatters. The user will have to register all attributes in the library before parsing any filters or formatters from strings. This can substantially reduce the binary size.
`BOOST_LOG_WITHOUT_SETTINGS_PARSERS` | Affects only the compilation of the library. If defined, none of the facilities related to the parsers for settings will be built. This can substantially reduce the binary size.
`BOOST_LOG_WITHOUT_DEBUG_OUTPUT` | Affects only the compilation of the library. If defined, the support for debugger output on Windows will not be built.
`BOOST_LOG_WITHOUT_EVENT_LOG` | Affects only the compilation of the library. If defined, the support for Windows event log will not be built. Defining the macro also makes Message Compiler toolset unnecessary.
`BOOST_LOG_WITHOUT_SYSLOG` | Affects only the compilation of the library. If defined, the support for syslog backend will not be built.
`BOOST_LOG_NO_SHORTHAND_NAMES` | Affects only the compilation of users' code. If defined, some deprecated shorthand macro names will not be available.
`BOOST_LOG_USE_WINNT6_API` | Affects the compilation of both the library and users' code. This macro is Windows-specific. If defined, the library makes use of the Windows NT 6 (Vista, Server 2008) and later APIs to generate more efficient code. This macro will also enable some experimental features of the library. Note, however, that the resulting binary will not run on Windows prior to NT 6. In order to use this feature Platform SDK 6.0 or later is required.
`BOOST_LOG_USE_COMPILER_TLS` | Affects only the compilation of the library. This macro enables support for compiler intrinsics for thread-local storage. Defining it may improve performance of Boost.Log if certain usage limitations are acceptable. See below for more comments.

You can define configuration macros in the `bjam` command line, like this:

    bjam --with-log variant=release define=BOOST_LOG_WITHOUT_EVENT_LOG define=BOOST_LOG_USE_WINNT6_API stage

However, it may be more convenient to define configuration macros in the "boost/config/user.hpp" file in order to automatically define them both for the library and user's projects. If none of the options are specified, the library will try to support the most comprehensive setup, including support for all character types and features available for the target platform.

The logging library uses several other Boost libraries that require building too. These are Boost.Filesystem, Boost.System, Boost.DateTime and Boost.Thread. Refer to their documentation for detailed instructions on the building procedure.

One final thing should be added. The library requires run-time type information (RTTI) to be enabled for both the library compilation and user's code compilation. Normally, this won't need anything from you except to verify that RTTI support is not disabled in your project.

##### Notes about compiler-supplied intrinsics for TLS

Many widely used compilers support builtin intrinsics for managing thread-local storage, which is used in several parts of the library. This feature is also included in the C++11 standard. Generally, these intrinsics allow for a much more efficient access to the storage than any surrogate implementation, be that Boost.Thread or even native operating system API. However, this feature has several caveats:

- Some operating systems don't support the use of these intrinsics in case if the TLS is defined in a shared library that is dynamically loaded during the application run time. These systems include Linux and Windows prior to Vista. Windows Vista and later do not have this issue.
- The TLS may not be reliably accessed from global constructors and destructors. At least MSVC 8.0 on Windows is known to have this problem.

The library provides the `BOOST_LOG_USE_COMPILER_TLS` configuration macro that allows to enable the use of this feature, which will improve the library performance at the cost of these limitations:

- The application executable must be linked with the Boost.Log library. It should not be loaded dynamically during run time.
- The application must not use logging in global constructors or destructors.