GCC: 指定最小共享库版本

Question

背景

我继承并维护一个与特定硬件密切耦合的Linux共享库，我们称之为libfoo.so.0.0.0。这个库已经存在一段时间并且“只是工作”。这个库现在已成为几个更高层应用程序的依赖项。

不幸的是，新的硬件设计迫使我创建具有更宽类型的符号，从而产生了libfoo.so.0.1.0。只有添加操作；没有删除或其他API更改。更新后符号的原始、窄版本仍以其原始形式存在。

此外，我有一个应用程序（例如myapp）依赖于libfoo。它最初是为支持库的0.0.0版本编写的，但现在已经重写为支持新的0.1.0 API。

出于向后兼容性原因，我希望能够通过编译标志构建myapp，以便支持旧的或新的库。给定构建的内核将始终具有精确已知的一版本库。

问题

很可能将来会再次更新libfoo。

1. 在构建myapp时，是否可以根据构建标志指定要链接的最小版本libfoo？

2. 我知道可以直接在构建CLI上指定库名。这会导致myapp需要精确地那个版本，还是后来的具有相同主要修订版号的库仍能够与之链接（例如libfoo.so.0.2.0）？我真的希望不必每次发布新的次要版本时都更新每个依赖应用程序的构建。

3. 有没有更聪明的方法以应用程序无关的方式实现这一点？

参考资料

如何在GCC中链接到特定版本的共享库？

- MysteryMoose

---

如果您已经将某些符号仅限于较高版本的库中，则无需担心确切的库版本；应用程序只能在包含它们使用的所有符号的库版本上运行。 - Ignacio Vazquez-Abrams

对于第二点，我认为你想给你的库一个 soname（libfoo.so.0 看起来不错）。 - Marc Glisse

Answer 1

您在描述外部库版本控制，即应用程序构建使用的是libfoo.so.0，libfoo.so.1等。此处有文档链接：here。

使用外部库版本控制需要确保运行时存在libfoo.so.x的完全相同版本。

一般而言，在Linux上这通常不是正确的技术方法，因为通过符号版本控制的神奇作用，单个libfoo.so.Y可以提供多个不兼容的同一符号定义，从而允许单个库同时为新旧应用程序提供服务。

此外，如果您只是一直添加新的符号，并且没有以不兼容方式修改现有符号，则没有理由增加外部版本。将libfoo.so保持在版本0，在其中提供一个int foo_version_X_Y;全局变量（以及所有先前的版本：foo_version_1_0、foo_version_1_1等），然后让应用程序二进制文件读取其所需的变量。如果一个应用程序需要一个新符号foo_version_1_2，并且在只提供foo_version_1_1的旧库中运行，则该应用程序将无法启动，并显示明显的错误。

- Employed Russian