检测/避免g ++符号冲突
如果两个共享库都暴露相同的全局范围符号，是否有检测和避免的方法？我们最近遇到了一个情况，我们有libA.so导出SuperCoolMethod()和libB.so也暴露了SuperCoolMethod()这将打破上述方法的前一个副本。这是在使用g ++ 4.0及更高版本的Linux上。所以隔离如果你链接到libA.so一切都会按预期工作，但一旦libB.so被添加到图片中，调用了错误的方法，调用会失败，导致正在执行的线程中止，而不通知我们潜在的问题。通过耗尽试验和错误，我们最终发现SuperCoolMethod()得到了破坏，并通知了供应商libB.so，以便__attribute__((visibility("hidden")))可以应用到他们的方法副本。检测/避免g ++符号冲突
动态加载库和通过dlopen和dlsym附加符号将工作。你将不得不编写代码才能做到这一点，但如果你真的被卡住了，这将是一个解决方案
因为这是C++库，每个库都应该在它们自己的命名空间中，所以不会发生冲突。
应该适用于，但不适用于第三方供应商。 – 2010-02-10 02:39:17
如果您可以“通知libB.so的供应商，以便__attribute（（visibility（”hidden“））”“您可以要求可以在非gnu编译器上工作的命名空间 – Mark 2010-02-10 13:21:54
作为解决方法，如果您只使用这两种方法中的一种，则它们在链接命令行上出现的顺序决定了最终可执行文件中最终使用的函数版本。
这不只是一个神器，它的定义行为，所以你可以依赖它（直到供应商修复它）。
嗯，这可能工作，因为我们从来没有使用需要显式调用有问题的函数，但它并没有告诉我如何发现冲突开始。 – 2010-02-10 02:40:56
nm和grep的组合会告诉你 – pm100 2010-02-10 18:05:21