Linux、GNU GCC、ld、版本脚本和 ELF 二进制格式——它是如何工作的？

Question

我正在尝试更多地了解 Linux 中的库版本控制以及如何将其全部投入使用。这是上下文：

-- 我有两个版本的动态库，它们公开了相同的接口集，比如libsome1.so和libsome2.so。

- 应用程序链接到libsome1.so.

-- 此应用程序用于libdl.so动态加载另一个模块，例如libmagic.so.

——现在libmagic.so是联防libsome2.so。很显然，在不使用连接器脚本隐藏符号libmagic.so，在运行时在接口的所有调用libsome2.so决心libsome1.so。这可以通过检查 返回libVersion()的值与宏的值来确认LIB_VERSION。

-- 所以我接下来尝试编译和链接libmagic.so一个链接器脚本，该链接器脚本隐藏了除 3 之外的所有符号，这些符号在其中定义libmagic.so并由它导出。这有效......或者至少libVersion()和LIB_VERSION值匹配（并且它报告版本2而不是1）。

-- 但是，当一些数据结构被序列化到磁盘时，我注意到一些损坏。在应用程序的目录中，如果我删除libsome1.so并在其指向的位置创建一个软链接libsome2.so，一切都按预期工作，并且不会发生相同的损坏。

我不禁想到这可能是由于运行时链接器对符号的解析存在一些冲突造成的。我已经尝试了很多东西，比如尝试链接libsome2.so以便所有符号都被别名化symbol@@VER_2（我仍然对此感到困惑，因为该命令nm -CD libsome2.so仍然将符号列为symbol和不列出symbol@@VER_2）......似乎没有任何效果！！！帮助！！！！！！

Answer 1

这并不能完全回答您的问题，但是...

首先，ELF 是 Linux 用于可执行文件（程序）、共享库以及目标文件（编译软件时发现的中间文件）的规范。目标文件以 .o 结尾，共享库以 .so 结尾，后跟零个或多个以句点分隔的数字，可执行文件通常没有任何扩展名。

通常有三种形式来命名共享库，第一种形式简单地以 .so 结尾。例如，名为 readline 的库存储在名为 libreadline.so 的文件中，通常位于 /lib、/usr/lib 或 /usr/local/lib 之一。该文件在使用 -lreadline 之类的选项编译软件时位于。-l 告诉编译器链接以下库。由于库会不时更改，因此它可能会过时，因此库会嵌入称为 SONAME 的东西。readline 的 SONAME 可能类似于 libreadline.so.2 的第二个版本主要版本的 libreadline。也可能有许多小版本的 readline 是兼容的，不需要重新编译软件。readline 的次要版本可能被命名为 libreadline.so.2.14。通常是 libreadline。so 只是到最新主要版本的 readline 的符号链接，在本例中为 libreadline.so.2。libreadline.so.2 也是 libreadline.so.2.14 的符号链接，它实际上是正在使用的文件。

库的 SONAME 嵌入在库文件本身中。文件 libreadline.so.2.14 中的某处是字符串 libreadline.so.2。当一个程序被编译并与 readline 链接时，它会查找文件 libreadline.so 并读取其中嵌入的 SONAME。稍后，当程序实际执行时，它会加载 libreadline.so.2，而不仅仅是 libreadline.so，因为这是第一次链接时读取的 SONAME。这允许系统安装多个不兼容的 readline 版本，并且每个程序将加载与其链接的适当的主要版本。另外，当将 readline 升级到 2.17 时，我可以在现有库旁边安装 libreadline.so.2.17，一旦我将符号链接 libreadline.so.2 从 libreadline.so.2.13 移动到 libreadline.so.2.17，