线上日志用到的是日志库，在全局有一个锁，导致在高并发的时候，容易因为锁竞争问题导致时延。在某些情况下，会因为同一个用户，同时访问某个变量，导致读写冲突使线上服务整体core掉（考虑到请求的间隔，为了应对偶发1%%的情形，如果加锁会对整体性能有一定的影响，所以当时权衡就没有加锁）。
于是就想把这个日志库的依赖去掉。正好大组内有人通过用boost.log来解决该问题，并且提供了分钟级别的切分封装，与当前线上的日志是兼容的，后续只需要压测一下，验证下功能即可。但我们的系统centos7所内置的boost库版本为1.53，但网上查询得知boost.log在1.54之后才有，所以考虑通过结合blade静态编译的方式将boost库整体封装到代码库中。
在编译boost.log中遇到了如下问题
1）DSO missing from command line
参考 https://segmentfault.com/a/1190000002462705
场景是：
- 我们有一个shared libA中，定义了函数foo()
- 另一个静态库libB显示地链接了libA
- 一个可执行文件bin_c显示地链接了libA
那么问题来了,如果bin_c中调用了函数foo(),那么编译能不能通过？
在binutils<2.22时，ld正常完成了，bin_c对于foo的调用经由libB，传递到了libA，链接成功。
但是当binutils>=2.22时，编译出错了，ld会报上面的错，告诉你foo这个symbol解析不到，这时，我们需要编译bin_c时，显示地链接libA才可以通过。
binutils2.22开始，其中的ld开始把--no-copy-dt-needed-entries默认打开，这样一来，ld不会再自动递归地解析链接的lib，而需要由用户来一一指定。
在blade的BUILD依赖中，显式的写上lib依赖即可。
2）使用动态库链接 时应注意:
要定义 BOOST_LOG_DYN_LINK 或者 BOOST_ALL_DYN_LINK
同时在build文件中也需要这样定义
3）编译支持多线程的regex和线程库
./bjam stage --with-regex --with-thread --build-type=complete --layout=tagged \
--toolset=gcc-4.9 architecture=x86 address-model=64 \
define=BOOST_ALL_DYN_LINK
经过编译好的lib，测试即可达到我们要的需求。