检测/避免 g++ 符号冲突答案

【问题标题】：Detecting / avoiding g++ symbol collisions检测/避免 g++ 符号冲突
【发布时间】：2010-02-10 01:48:40
【问题描述】：

如果两个共享库都公开相同的全局范围符号，有没有办法检测和避免？我们最近遇到了libA.so 导出了SuperCoolMethod() 和libB.so 的情况，这也暴露了SuperCoolMethod() 这将破坏上述方法的先前副本。这是在使用 g++ 4.0 及更高版本的 Linux 上。因此，如果您单独链接libA.so，一切都会按预期工作，但是一旦将libB.so 添加到图片中，就会调用错误的方法，并且调用将失败，导致执行线程中止，而不会通知我们潜在的问题。经过反复试验，我们最终发现SuperCoolMethod() 被破坏并通知libB.so 的供应商，以便__attribute__((visibility("hidden"))) 可以应用于他们的方法副本。

【问题讨论】：

标签： c++ g++ shared-libraries

【解决方案1】：

因为这是 C++，所以每个库都应该在自己的命名空间中，因此不会发生冲突。

【讨论】：

应该，但不是，它来自第三方供应商。
如果您可以“通知 libB.so 的供应商以便 __attribute((visibility("hidden"))”您可以要求在非 gnu 编译器上也可以使用的命名空间

【解决方案2】：

动态加载库并通过 dlopen 和 dlsym 附加符号会起作用。您必须编写代码才能做到这一点，但如果您真的被卡住了，那将是一个解决方案

【讨论】：

嗯，这可能有效，因为我们从不使用显式调用相关函数的需要，但它并没有告诉我如何发现冲突。
结合 nm 和 grep 会告诉你

【解决方案3】：

作为一种变通方法，如果您只使用这两种方法中的一种，则它们在 link 命令行中出现的顺序决定了您最终会使用哪个版本的函数可执行文件。

这不仅仅是一个工件，它是定义的行为，因此您可以依赖它（直到供应商修复它）。

【讨论】：