在 Linux 代码中混合不同版本的库答案

【问题标题】：Mixing different versions of libraries in code for Linux在 Linux 代码中混合不同版本的库
【发布时间】：2010-11-01 21:48:33
【问题描述】：

我正在处理的程序静态链接到 3rdPartyLibrary.lib。

我们想利用同一个 3rdPartyLibrary 的更新版本，比如 3rdPartyLibraryNewVersion.lib。

因此决定将 3rdPartyLibraryNewVersion.so 作为动态链接库包含在内，并通过名为 wrapper.so 的包装动态库包含在内。我们希望同时使用 3rdPartyLibrary 的新版本和旧版本，但在程序的不同方中。

我们的解决方案是静态链接旧的 3rdPartyLibrary，同时动态链接到包装库到 3rdPartyLibraryNewVersion。

程序 --- 静态链接 ---> 3rdPartyLibrary.lib。 --- 动态链接 --> wrapper.so --- 动态链接 ---> 3rdPartyLibraryNewVersion.so.

这可能吗？

我们遇到的问题是，当 wrapper.so 使用测试可执行文件时，当从静态链接到 3rdPartyLibrary.lib 的程序调用包装器时，它在 3rdPartyLibraryNewVersion.so 内失败。

我做错了什么吗？

我知道正确的方法是将我们的代码更新为 3rdPartyLibrary.lib 但这太繁琐了...

谢谢，

提姆

【问题讨论】：

【解决方案1】：

你忽略了它是如何使用你的包装方案失败的......

无论你怎么做，你都可能会遇到命名空间冲突，这会导致事情失败或以意想不到的方式运行。

您知道正确的做法：更新您的代码。如果它太乏味，那么你的代码一定不值得付出努力。如果您必须使用新功能编写代码，那么值得更新。你想要的最后件事是创建一个你现在被绑定到同一个库的两个不同且不兼容的版本的情况。如果你以后必须维护它，你会踢自己。如果其他人必须维护它，他们会追捕你并击败你。以正确的方式去做。

【讨论】：

我知道我们正在走一条滑坡，但另一条路并不容易。根据 gdb 的说法，无论如何，该程序的核心文件表明该程序在 3rdPartyLibraryNewVersion.so 内崩溃。 3rdPartyLibraryNewVersion 中的一些内部调用是在发送 SIGSEGV 之前进行的。您能否详细说明命名空间冲突？链接的包装器库将调用 3rdPartyLibraryNewVersion（或者我认为），您的意思是程序会混淆并调用静态链接库吗？