共享对象 .so 文件中的动态链接答案

【问题标题】：Dynamic linking in a shared object .so file共享对象 .so 文件中的动态链接
【发布时间】：2020-06-21 18:10:25
【问题描述】：

我想使用一个使用 glibc2.14 的 SDK/库。我的机器有glibc2.12。我在一个单独的位置安装了 glibc2.14。通过使用编译选项 --rpath 在我的可执行文件中使用了 SDK，它运行良好。

现在，我想在共享对象二进制文件 (.so) 中使用 SDK（使用 glibc2.14）。我尝试了 --rpath 和 --dynamic-linker 选项，但未加载共享对象，它在运行时给我一个错误 - /lib64/libc.so.6: version ``GLIBC_2.14'' not found (required by /usr/local/lib/libsdk.so.1).

如何让共享对象二进制查看glibc2.14？

【问题讨论】：

我强烈建议不要尝试使用定制的 glibc。发行版应用了各种补丁和自定义，尝试构建自己的可能会导致损坏的库无法与系统上的其他任何东西一起使用。
我已将它安装在不同的位置，据我了解，只有明确指向该位置的应用程序才会使用其他 glibc。
这可能是真的，但是您构建的版本可能与您的发行版编译的其他 glibc 二进制文件的 ABI 不兼容（听起来不兼容），因此请使用系统上的任何其他共享库可能会也可能不会。最好只升级您的操作系统。

标签： linux shared-libraries glibc

【解决方案1】：

现在，我想在共享对象二进制文件 (.so) 中使用 SDK（使用 glibc2.14）。

你不能。

正如this answer 解释的那样，ld-linux 和libc.so 必须来自相同的 GLIBC 版本。

由于ld-linux 由主可执行文件确定（在静态链接时硬编码到其中），它不会匹配您自定义的libc.so.6 无论您做什么编译你的.so。

此外，在构建.so 时指定--dynamic-linker 是没有意义的：加载.so 是ld-linux 的工作，因此根据定义ld-linux 必须已经加载在任何.so 加载到进程之前。

附：如果可以让您的.so 使用不同的libc.so.6，结果将是（几乎）立即崩溃，因为libc.so.6 不适合在加载多个副本时工作相同的过程。

更新：

升级我的操作系统，我认为这是不可能的，因为我正在为客户开发软件并让他们升级并不容易。二是要求SDK供应商用glibc2.12重新编译。

GLIBC-2.14 was released 9 年前。您的供应商“仅”支持 2.14（及更高版本）并非不合理，您的客户运行这么旧的操作系统有些不合理。

我认为您有第三种可能的选择：让客户端并行安装较新的 GLIBC，并使用 --rpath 和 --dynamic-linker 标志构建他们的主可执行文件（正如您所做的那样）。这样他们的二进制文件就可以毫无问题地加载您的 SDK。

【讨论】：

谢谢。看起来我有两个选择 - 升级我的操作系统，我认为这是不可能的，因为我正在为客户开发软件并让他们升级并不容易。其次是要求 SDK 供应商使用 glibc2.12 重新编译。
谢谢。我得到了主要的可执行部分，这就是我对我的应用程序所做的。然而，另一个组件实际上是一个 PAM 模块。将由不受我控制的可执行文件加载的共享对象二进制文件（.so 文件）。例如：gnome-screensaver 或 gdm-password。我正在考虑的另一个选项是创建我自己的可执行文件并让 PAM 模块通过某种 IPC 方法与我的 exe 对话。