ATS 6.2.1打release版本rpm包时插件中出现undefined symbol的问题追踪

问题场景
我基于ATS 6.2.1社区版整合进一些插件，发现debug版本一直运行好好的，后来改为release版本(就是configure时不加--enable_debug)时，安装后显示下面的出错信息
[May 11 11:33:18.659] Server {0x2ab7cd116700} ERROR: <RemapConfig.cc:1360 (remap_parse_config_bti)> [ReverseProxy] failed to add remap rule at /etc/trafficserver/remap.config line 206: Can't load plugin "/usr/lib64/trafficserver/plugins/libtsrefinequery.so" - /usr/lib64/trafficserver/plugins/libtsrefinequery.so: undefined symbol: _ZN17RefineQueryConfig7IsWhiteEv

这会ATS反复重启，后果非常严重！

问题定位
根据报错的信息，找到源码Remap.config.cc中的相应代码位置
remap_parse_config_bti()
remap_load_plugin()
dolmen()
dlerror()
发现这里的报错信息实质是就是，dlopen调用一个插件的so，发现里面没有需要的符号信息，就报这里的错误

问题分析
1.一些无谓的摸索
上述场景写个demo就能验证出来，所以网上的观点集中在，没有加载到动态库之类的简单问题，仔细分析之后，发现都不太切合我的问题场景。因为这里的出错信息已经明确说，
已经找到动态库，都是没有里面的符号_ZN17RefineQueryConfig7IsWhiteEv
2.debug版本一切正常，但是release版本就有这个问题
3.将debug版本中的libtsrefinequery.so覆盖release版本中的同名动态库，发现正常

最自然最直接的方法，我最后觉得还是直接分析动态库中的符号差异，比较接地气。

linux 查看so文件导出的符号 
#nm -D ****.so，
#nm ****.a

下面是nm对应的用法

下面是对比两个动态库中的符号差异


查明原因

通过研究该插件中的相关源码，发现一个可疑点

在一个c文件中定义的inline函数是不能在其它c文件中直接使用.也就是，这个inline会使编译器的行为产生一些差异。


解决方法

去掉该inline

下面是去掉inline之后重新打包安装之后的动态库符号表对比图，发现_ZN17RefineQueryConfig7IsWhiteEv由原来的W类型变为了T类型，这正是我们需要的结果。

再次安装确认，debug和release版本都统一了，没有问题。

参考文献

[1].http://blog.csdn.net/qq_34488499/article/details/51873341

[2].http://daisy8867.blog.51cto.com/1043582/1201568/
[3].http://blog.csdn.net/shuanghujushi/article/details/23025055