第三方共享库符号冲突：让lib2.so调用自身foo()的链接方案

这个问题本质是动态链接器的全局符号查找机制在搞鬼：默认情况下，当共享库中的函数调用同名符号时，会优先使用进程中第一个加载的库的符号。所以你把lib1.so放前面时，lib2.so的bar()会"抢"用lib1的foo()；调换顺序后，主程序又会拿到lib2的foo()，两边都不满足需求。

既然没法修改第三方库的构建流程，我们可以通过链接器选项来强制lib2.so内部的函数调用优先绑定自身的符号，具体有两种靠谱的方案：

方案一：用链接器选项精准控制符号绑定（推荐） #

使用-Bsymbolic-functions选项（只对函数生效，比全量的-Bsymbolic更安全），配合--push-state/--pop-state来只对lib2.so应用这个规则，不影响lib1.so：

g++ a.cpp lib1.so -Wl,--push-state,-Bsymbolic-functions lib2.so -Wl,--pop-state

选项解释： #

• -Wl,--push-state：先保存当前的链接器配置状态
• -Bsymbolic-functions：告诉链接器，接下来处理的lib2.so，内部的函数调用优先用自身的符号定义，不会去全局符号表找同名函数
• -Wl,--pop-state：恢复之前的链接器配置，保证lib1.so的符号查找逻辑不受影响，主程序依然能正常调用lib1的foo()

如果你的链接器版本较新，也可以简化成全局应用-Bsymbolic-functions（只要lib1.so内部没有调用同名的foo()，就不会有问题）：

g++ a.cpp -Wl,-Bsymbolic-functions lib1.so lib2.so

方案二：修改lib2.so的导出符号表（备选，有风险） #

如果上述链接器选项不生效（比如用了旧版本链接器），可以尝试去掉lib2.so中foo()的导出符号，让它不在全局符号表中暴露：

strip -K foo lib2.so

这样动态链接器查找foo()时只会找到lib1.so的版本，而lib2.so内部的bar()因为是内部引用，依然能调用自身的foo()。不过这个方法要注意：如果lib2.so还有其他API依赖导出的foo()，这么做会破坏库的功能，所以只建议在确认lib2.so的foo()不需要被外部调用时使用。

内容的提问来源于stack exchange，提问作者user3677630