c++ - 使用同一库的多个版本时的符号解析

Question

我有一个作为第三方应用程序(app.exe) 的一部分运行的solaris 共享对象(common.so 文件)。我无权访问该应用程序的源代码。为此，我需要添加发布 http 请求的功能。我的计划是将 libcurl 与 openssl 一起使用。棘手的部分是 app.exe 已经依赖于旧版本的 curl (7.14)，该版本不支持 tls v1.2 的 ssl。

我下载了源代码并构建了curl (7.55.1) 和openssl .a 文件。我还能够构建 common.so 并静态依赖于这些存档文件。 ldd 不显示对curl 或ssl .so 文件的依赖性，也不会报告任何“未找到符号”错误。

有了这个结果，我期望当 so 作为应用程序的一部分运行时，我的版本的curl 会被调用，但事实并非如此。相反，curl_version() 显示旧版本，并且出现错误未知 ssl 协议(protocol)错误

我正在使用solaris studio编译器。该应用程序不直接依赖于curl库，而是依赖于另一个.so文件，该文件导出与curl同名的符号。我从 nm 意识到，我假设这个 .so 文件也静态链接curl。

Answer 1

当 app.exe 加载两个相关 SO 时，它会将每个 SO 的函数添加到其符号表中。现在，两种可能的情况之一必须发生(其中一种实际上是操作系统细节，但与这里无关......):

1. 新版本会先于旧版本加载，并且旧版本会覆盖新版本的条目。
2. 新版本在旧版本之后加载，并且由于表中已有条目，因此不再更新。

现在是最干净的解决方案 - 如果适用，i。 e.如果您有权访问源代码 – 将更新其他 SO 以使用较新版本的curl。如果这样做，请考虑将curl创建为新的SO，而不是将其静态链接到common.so和其他SO中。

否则，要直接解决问题，您必须切换应用程序加载 SO 的顺序，这可能意味着反编译 app.exe 并在 SO 的链接顺序发生变化的情况下重建它。那么问题来了:那时可能有两个版本的 app.exe，您必须确保只有正确的版本与您的 common.so 一起分发。也是潜在的麻烦来源......

除此之外，我能想到的最好的解决方法是:

您可以将curl 前缀从curl_ 修改为e。 G。 curl_755_。不过，不要手动尝试，这样您很可能会发疯...使用脚本(例如 perl 或 python)代替。如果您更新了curl源，您可以再次运行它...

更快的版本，但可能不安全:只需替换任何出现的情况。更安全:在第一次运行时识别外部可见的函数(可能还有全局对象)并将它们保存在映射中，然后将映射中包含的任何出现的字符串替换为相应的值。

后一种方法(映射)还允许在以下形式的头文件中生成宏:

#define curl_xyz curl_755_xyz

这些宏允许 common.so 的源看起来就像使用了原始的 curl 源一样......