Linux，GNU GCC，ld，版本脚本和ELF二进制格式-如何工作？

我试图了解有关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一个链接描述文件，该脚本隐藏除其中定义libmagic.so和导出的3个符号以外的所有符号。这行得通...或至少libVersion()和LIB_VERSION值匹配（并且报告版本2不是1）。

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

我忍不住认为这可能是由于运行时链接程序的符号解析中的某些冲突引起的。我尝试了很多事情，例如尝试链接，libsome2.so以便所有符号都被链接到symbol@@VER_2（我仍然感到困惑，因为该命令nm -CD libsome2.so仍将符号列为symboland而不是symbol@@VER_2）……似乎没有任何作用！！！救命！！！！！！

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

首先，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。因此，在本例中，这只是指向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，