在 ELF 库文件名中，主要和次要版本在兼容性方面有多重要？

Question

我有一组安装在 Linux 机器上的二进制文件。它们需要libgfortran 库，但在执行时会显示以下消息：

error while loading shared libraries: libgfortran.so.2: cannot open shared object file: No such file or directory

机器已经安装了libgfortran，但是库文件的名称是libgfortran.so.1.0.0（和libgfortran.so.1链接到它）。

令我惊讶的是，只需将libgfortran.so.2 与libgfortran.so.1 建立一个符号链接，如下所示：

ln -s /usr/lib64/libgfortran.so.1 /usr/lib64/libgfortran.so.2

这解决了我的问题，并且二进制文件能够运行，显然没有错误。

我的问题是——他们为什么还要跑呢？

是否没有内置机制来检测 API 版本何时不同，还是仅基于文件名？

如果有 API 检测 - 那么应该没有符号错误吗？

确实，如果库之间具有不同的主要版本实际上是兼容的，那么它们的目的是什么？

（回答者注意：我的问题不是关于libgfortran，这只是一个说明性的例子。）

Answer 1

为什么它会运行？

它运行是因为在 .so 中找到了所有依赖符号，所以它加载了

是否有检测 API 版本差异的内置机制？

有可用的符号版本控制支持，但您必须对其进行编程。这完全取决于开发者是否使用它。

如果有API检测...？

同样，有可用的符号版本控制，但并不完全相同。

如果仍然兼容，拥有不同主要版本的目的是什么

这取决于开发者。

但请注意，可能只有您使用的 API 的元素在两个版本之间是兼容的。代码很可能会在后台默默地破坏您的数据，而您直到后来才意识到这一点。

Answer 2

对于与先前版本兼容的 ABI 版本，次要版本通常会增加。 IE。当后者更新时，应用程序可以并且将使用新的次要版本共享库。

对于与以前的主要版本不兼容 ABI 的版本，主要版本通常会增加。

通常，一个共享库具有三个文件系统名称，例如：

lrwxrwxrwx 1 max max       13 May 13 11:13 libfix.so -> libfix.so.0.0
lrwxrwxrwx 1 max max       13 May 13 11:13 libfix.so.0 -> libfix.so.0.0
-rwxrwxr-x 1 max max  1665544 May 13 11:13 libfix.so.0.0

未版本化的libfix.so 只是完全版本化的符号链接。当您使用 ld 链接器将您的应用程序与 -lfix 链接时使用它。

libfix.so.0.0 是实际的共享库。但是，此库与 -hlibfix.so.0 链接器选项链接：

   -h name
   -soname=name
       When creating an ELF shared object, set the internal DT_SONAME
       field to the specified name.  When an executable is linked with a
       shared object which has a DT_SONAME field, then when the executable
       is run the dynamic linker will attempt to load the shared object
       specified by the DT_SONAME field rather than the using the file
       name given to the linker.

所以，当应用程序启动时，运行时链接器ld.so 实际上会查找libfix.so.0，它是指向具有相同主编号的最新版本共享库的符号链接。当libfix.so.0.0 更新为libfix.so.0.1 时，这些符号链接将更新为指向该新版本。现有的和新的应用程序会在您下次启动或链接它们时开始使用新版本的共享库。