编译boost.log模块遇到的一些问题

线上日志用到的是日志库,在全局有一个锁,导致在高并发的时候,容易因为锁竞争问题导致时延。在某些情况下,会因为同一个用户,同时访问某个变量,导致读写冲突使线上服务整体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

场景是:

  1. 我们有一个shared libA中,定义了函数foo()
  2. 另一个静态库libB显示地链接了libA
  3. 一个可执行文件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,测试即可达到我们要的需求。

 

猜你喜欢

转载自www.cnblogs.com/westfly/p/10372936.html
0条评论
添加一条新回复