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

时间:2010-02-10 01:48:41

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

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

3 个答案:

答案 0 :(得分:1)

由于这是C ++,每个库都应该位于自己的命名空间中,因此不会发生冲突。

答案 1 :(得分:0)

动态加载库并通过dlopen和dlsym附加符号会起作用。您必须编写代码来执行此操作,但如果您真的被卡住了,那将是一个解决方案

答案 2 :(得分:0)

作为解决方法,如果您只使用这两种方法中的一种,它们在链接命令行中的显示顺序将决定您最终在最终版本中使用的功能版本可执行文件。

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