Boost.Log v2 : 3.安装

安装及兼容性

平台和编译器

本程序库可以编译运行在各主流编译器上。在以下平台都编译成功且通过了测试：

• Windows XP, Windows Vista, Windows 7. MSVC 8.0 SP1, MSVC 9.0 及以上版本。
• Linux. GCC 4.5 及以上版本. 旧版本GCC应该也可以用，但尚未试过。
• Linux. Intel C++ 13.1.0.146 Build 20130121。
• Linux. Clang 3.2 及以上版本。

不支持以下平台，在这些平台上编译很可能会失败：

• 包含有非标准C++11 程序库的C++11 编译器（例如Clang 搭配GCC 4.2版本的 libstdc++)。拜托，在C++11 模式下开发时请用标准C++11 程序库。
• MSVC 8.0 （没有SP1补丁包）及以下版本。
• GCC 4.2及以下版本。
• Borland C++ 5.5.1 （免费版），更高版本能否支持尚不确定。
• Solaris Studio 12.3 及以下版本。
• Windows 9x, ME, NT4, 2000 及以下版本。

对Boost 支持的所有硬件架构，Boost.Log 都是兼容的。但请注意，对32 位x86 架构，本库的最低硬件要求是i586 CPU。

GCC 用户

从4.5版本开始，GCC 支持链接时优化（LTO），这种情况下大多数优化和二进制码的生成都是在链接时期完成。这有助于执行许多高级优化并能提升代码运行效率。但不幸的是，在一些对源码有不同优化项要求的项目中LTO 表现不佳，而Boost.Log 恰巧是其中之一，她有一些文件对现代CPU 做了优化表述，但这些表述不适于那些老CPU。如果启用LTO，编译得到的Boost.Log 无法兼容老CPU（GCC bug），在运行时往往会导致崩溃。这个问题在GCC 5.1及以上版本中已经修复。因此，对于低于5.1版本的GCC Boost.Log不提供LTO支持。

在使用-march=native 参数编译时，有个GCC 的bug 会导致编译失败。我们的建议是避免使用-march=native 参数进行编译（bjam 属性中也不要用instruction-set=native），并显示指明目标CPU架构（例如，instruction-set=sand-bridge）。

MinGW, Cygwin 及 Visual Studio Express Edition 用户

使用这些编译器前要做些准备工作。首先，如果是MinGW 或Cygwin 用户请首先确认安装使用了最新版本的GCC。如果用GCC 3.x 版本做编译，十有八九会失败。

其次，本库有时会用到Message Compiler（mc.exe），但MinGW、Cygwin和一些版本的MSVC Express Edition 不提供此工具。程序库编译脚本会自动探测系统中有没有可用的Message Compiler，如果没有则会禁用Event Log 相关功能。如果要用Event Log 但又没装Message Compiler，你有3条路可以走，我们推荐的一条是搞个原版的mc.exe。Windows SDK 里就有这个程序，从Microsoft 网站上下载SDK 是免费的（例如，用这个）。在Visual Studio 2010 Express Edition 中也包含此工具。别忘了在PATH 环境变量中包含mc.exe 的路径，编译时要用到。

另一条路是尝试MinGW 或Cygwin 中发行的windmc.exe，这个是原版mc.exe 的模拟程序。如果走这条路你需要对Boost.Build 文件打补丁（具体而言，文件 tools/build/tools/mc.jam），这里有方法。打完补丁就可以用mc-compiler=windmc 告诉bjam 去编译程序库了。

如果因为某些原因，Message Compiler 检测失败了，你可用在编译库文件时指明禁用Event Log 后端，添加宏定义BOOST_LOG_WITHOUT_EVENT_LOG 就行了。这样就移除了对Message Compiler 的依赖。（关于配置项的更多细节，其他章节里会有描述。）

Windows XP 上的MinGW 用户可能会被msvcrt.dll 中bug 影响，msvcrt.dll 是绑定在操作系统上的。这个bug 反应为在格式化log 条目时库代码会崩溃。不是只有Boost.Log 才有这个问题，其他一些和本地化及IO流管理有关的应用场景中也会有此问题。

Cygwin 用户补充

Cygwin 提供的支持十分有限。Cygwin 中默认的GCC 版本（本文写作时是4.5.3版）因编译器错误无法编译程序库。你必须从源码开始重新编译GCC。即便如此一些Boost.Log 的功能仍然不可用。具体而言，基于socket 的syslog 后端不可用，因为它基于Boost.ASIO，而后者在Cygwin 环境中是编译不了的。但原生的syslog 仍可以工作。

配置及编译

本程序库包含有需要单独编译的部分，编译方法见Getting Started。需要说明的是，如果在您的项目中有不止一个使用Boost.Log 的模块（比如一个.exe文件和多个dll文件），应该编译使用共享库。如果您只有一个可执行文件或一个单独的模块使用Boost.Log，编译静态库也是可以的。

编译库时使用如下宏定义做配置：
表1.1. 宏配置

宏名称 配置作用 BOOST_LOG_DYN_LINK 如果在用户代码中定义，库文件将被视作动态链接库（dll或so文件）。否则库文件将被视作静态库。在所有用到日志功能的文件中这个宏都必须显示定义或显示不定义，只要这些文件参与了编译。支持自动链接的平台要用到这个宏配置。 BOOST_ALL_DYN_LINK 功能和BOOST_LOG_DYN_LINK 相同，但也会影响到其他Boost 库。 BOOST_USE_WINAPI_VERSION 这个宏配置是Windows 平台专有的。对库编译和用户代码编译都会产生影响。这个宏配置用来选择目标Windows 版本，对包括Boost.Log 在内的各个Boost 库都会产生影响。编译出的代码在低于目标版本的Windows 上运行时很可能会出错，但因为能使用新的OS特性，编译出的代码在性能方面可能会有所提升。这个宏应该被定义成整数值，和目标版本的_WIN32_WINNT 保持一致。 BOOST_LOG_NO_THREADS 定义了这个宏就不会再支持多线程。对库编译和用户代码编译都会产生影响。如果探测到不支持线程功能，这个宏会被自动定义。 BOOST_LOG_WITHOUT_CHAR 定义了这个宏就不会再支持窄字符（CHAR 型编码）日志。对库编译和用户代码编译都会产生影响。 BOOST_LOG_WITHOUT_WCHAR_T 定义了这个宏就不会再支持宽字符（WCHAR 型编码）日志。对库编译和用户代码编译都会产生影响。 BOOST_LOG_NO_QUERY_PERFORMANCE_COUNTER 这个宏是Windows 平台专用的。对库编译和用户代码编译都会产生影响。定义了这个宏就不会再支持定时器属性中的QueryPerformanceCounter API。这会明显降低读时间精度。这个宏配置是用来解决旧版本AMD Athlon CPU 上的潜在问题的，具体看这里和这里。还有一些其他硬件芯片也不支持这个API，具体看这里。 BOOST_LOG_USE_NATIVE_SYSLOG 只影响库编译。如果有什么幺蛾子搞得原生SysLog API 检测失败可以用这个宏强行支持它。 BOOST_LOG_WITHOUT_DEFAULT_FACTORIES 只影响库编译。如果定义了这个宏配置，那么编译出的parser 设置中将不包含默认的filter 和formatter 工厂（译者：parser、filter、formatter 都是Boost.Log 库中业务抽象）。用户必须在对字符串解析前自行注册库的各种属性，这样才能知道该用哪些filter 和formatter。这样做能实质性的缩小二进制文件大小。 BOOST_LOG_WITHOUT_SETTINGS_PARSERS 只影响库编译。如果定义了这个宏配置，和parser 设置相关的东西都不会被编译进二进制文件，这明显能缩小二进制文件尺寸。 BOOST_LOG_WITHOUT_DEBUG_OUTPUT 只影响库编译。如果定义了这个宏配置，Windows 上的debugger 输出功能将不被编译进二进制文件。 BOOST_LOG_WITHOUT_EVENT_LOG 只影响库编译。如果定义了这个宏配置，Windows 上的event log 输出功能将不被编译进二进制文件。定义这个宏之后也不会再要求安装Message Compiler。 BOOST_LOG_WITHOUT_SYSLOG 只影响库编译。如果定义了这个宏配置，syslog 后端将不被编译进二进制文件。 BOOST_LOG_NO_SHORTHAND_NAMES 只影响用户代码。如果定义了这个宏，一些不赞成使用的宏简写将不再可用。 BOOST_LOG_USE_COMPILER_TLS 只影响库编译。这个宏配置会使能编译器自带的线程内部存储。这个宏也许会提升Boost.Log 的性能，前提是某些使用限制可以被接受。详细说明见下面的注释部分。 BOOST_LOG_USE_STD_REGEX
BOOST_LOG_USE_BOOST_REGEX
BOOST_LOG_USE_BOOST_XPRESSIVE 只影响库编译。这些宏用来指定解析字符串和设置时Boost.Log 使用std::regex 还是Boost.Regex 或是Boost.Xpressive。如果不定义她们，Boost.Log 默认会使用Boost.Regex。使用std::regex 或Boost.Regex 能产生明显小些的可执行文件，Boost.Regex 通常在运行时是最快的。使用Boost.Xpressive 可以排除对Boost.Regex 库的依赖。要注意的是，这些宏不会影响用户创建的过滤表达式。

你可以在使用bjam 命令行时定义这些宏配置项，比如：

bjam –with-log variant=release define=BOOST_LOG_WITHOUT_EVENT_LOG define=BOOST_USE_WINAPI_VERSION=0x0600 stage

但是在 boost/config/user.hpp 文件中定义这些宏会更方便一些，这样做能同时在库工程和用户项目中使能宏。如果一个宏也不定义，库工程会尝试用最合情理的配置，包括支持各种字符类型和目标平台可用的特性。

本库用到的其他Boost 库也需要编译。她们是Boost.Filesystem，Boost.System，Boost.DateTime，Boost.Thread 和Boost.Regex（如果配置的话）。她们的具体编译事项要看各自文档。

最后，还有一件事要做。日志库需要运行时类型信息（RTTI），在编译库文件和用户代码时都要使能她。通常，只要检查你的工程中没有禁用RTTI就行了。

注释：编译器内置的TLS功能

许多广泛使用的编译器都内置有管理线程局部存储（TLS）的功能，这个功能在库的许多地方都会被使用。这个特性也是C++ 11标准的一部分。
通常这些内置功能会允许更高效的访问存储空间，要比其他途径例如Boost.Thread 甚至原生的系统API 还要高效。然而，使用这个特性还要注意以下几点：

• 有些操作系统不支持以动态链接库的形式使用TLS，动态库是在程序运行时才加载的。这些操作系统包括Linux 和低于Windows Vista 的Window 版本操作系统。Windows Vista 及更新的Windows 操作系统没有这个问题。
• 在全局变量的构造和析构函数中使用TLS 是不可靠的。至少在MSVC 8.0 上这是个已知问题。

程序库提供了BOOST_LOG_USE_COMPILER_TLS 宏配置来使能TLS，你可以用她来提升运行效率，但要遵守下面的规则：

• 应用程序必须要链接Boost.Log 库，而不能在运行时动态加载她。
• 在全局的构造和析构函数中不能写日志。

要注意BOOST_LOG_USE_COMPILER_TLS 只能控制Boost.Log 使用TLS 但其他被用到的库是不受控制的。比如Boost.ASIO会默认使用TLS。如果要让Boost.Log 完全脱离编译器内置的TLS, 在其他库里也要禁用她（对Boost.ASIO 可以在编译和使用时定义BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION ）。

注释：对wchar_t 的支持

对一些编译器尤其是MSVC，有选项禁用原生的wchar_t 类型，她会用typedef 来模拟wchar_t。从C++ 语言的视角看这是欠妥的，但对于兼容那些难以更新升级的旧代码这是有用的。

Boost库（当然也包括Boost.Log）默认以支持原生wchar_t的方式编译。本文写作时，用户还需要修改Boost.Build才能开启模拟方式。您可以让Boost.Log以模拟wchar_t方式工作，但务必牢记以下几点：

编译期配置决定了编译后Boost.Log二进制文件中的导出符号。用户代码必须使用和编译Boost.Log时相同的配置，否则会出现链接错误。
因为在模拟方式中wchar_t型和整型是无法分辨的，部分库行为会和使用原生wchar_t的正常模式有所不同。特别是宽字符文字（译者：比如中文）有可能会被拒绝使用或出现另类格式化。
模拟方式未通过全面测试，可能会出现意外。因此不鼓励使用模拟方式，我们应该尽量避免使用它。在未来版本中有可能不再支持模拟方式。

---

翻译：[e-mail]
声明：本文旨在技术交流，可以转载，但如果是商业用途请务必和原作者确认。本人保留追诉权利。