linux - 在 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 链接到它)。

令我惊讶的是，通过简单地创建一个符号链接(symbolic link)libgfortran.so.2 到libgfortran.so.1，如下所示:

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

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

我的问题是 - 他们为什么要跑？

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

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

事实上，如果它们实际上是兼容的，那么在库之间使用不同的主要版本的目的是什么？

(回答者请注意:我的问题不是关于 libgfortran，这只是一个说明性示例。)

Answer 1

why did it run at all?

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

is there an inbuilt mechanism to detect API version differences?

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

If there is API detection ...?

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

What's the purpose of having different major versions if it's still compatible

这取决于开发者。

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