记录一次采坑--如何处理Linux动态库同名函数？

一、背景介绍

需求描述：业务提供一个鉴权的静态库，我只需要从url 和 参数中提取相应的参数传给业务的静态库，将静态库的处理结果直接返回给业务（return < 0, 直接返回403）。

但是最近业务反馈，请求部分url直接返回Error:-1015错误，不符合预期。

二、分析过程

业务刚开始反馈问题，我的第一反应：怎么可能是我的问题，我就仅仅写了一个so（暂时命名1.so），直接调用了你们静态库，这个-1015不就是你们库返回的结果。 有问题也是业务提供的库有问题。 或者就是业务配置不正确。
我临时解决方案：

1. 让业务检查配置 ，是否和校验级别有关系？
2. 双方md5的静态库，本地调试结果是否正确？
3. 上述方案不行: 采用最挫的方案， 既然静态库吐出来的结果，疯狂加printf，我就不信这个邪了

最后还是走到方案3，业务说printf的结果不符合预期，经业务提醒，突然意识到是不是调用链接到其他库的xx_func？

因为项目比较大， 涉及的库比较多，我用nm认真检查了编译时加载的库，竟然还真找到一模一样的接口xx_func

nm   ./lib/liba.a | grep xx_func

编译代码的时候，赶紧去掉了同名函数库（因为在makefile文件编译的时候某些公共库默认都会编译进去）。重新编译版本。

没有想到，去掉同名函数库，还是存在问题，为什么呢？到底是哪里的问题？

随手直接 nm *.so | grep xx_func，结果在另外一个so（暂时命名2.so）中，发现了同名函数xx_func。 看了一下配置，程序启动的时候首先加载了2.so动态库， 1.so是在2.so后面加载的. 因为优先加载哪个库，就使用哪个库的同名函数，并不会覆盖的情况（自己现网测试 + 测试代码）

到这里问题的原因也算是找到了，下面接着就是如何解决问题？

三、解决方案

1. 最简单的方案 – 修改函数名称

因为业务本身提供的静态库，用nm查看函数也不多，为了安全起见，修改每个函数的名称（增加一些业务私有的东西）。 批量修改函数名可直接使用sed

2. -fvisibility=hidden – 最安全最推荐的做法

现在C/C++这一块有几十年的历史，该踩的坑大家都应该踩过去了。gcc编译器就直接提供-fvisibility=hidden编译选项，直接让库函数global可见变成local可见， 使用__attribute__((visibility("default")))直接将需要的函数暴漏在外面就行

-fvisibility=[default|internal|hidden|protected]
　　Set the default ELF image symbol visibility to the specified option—all symbols are marked with this unless overridden within the code. Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provi