linux - GCC:指定最低共享库版本

Question

背景

我继承并维护了一个与特定硬件紧密耦合的Linux共享库；我们称它为 libfoo.so.0.0.0。这个库已经存在了一段时间并且“刚刚工作”。该库现在已成为多个高层应用程序的依赖项。

现在，不幸的是，新的硬件设计迫使我创建具有更广泛类型的符号，从而导致 libfoo.so.0.1.0。只有补充；没有删除或其他 API 更改。更新后的符号的原始缩小版本仍然以其原始形式存在。

另外，我有一个依赖于 libfoo 的应用程序(例如，myapp)。它最初是为支持库的 0.0.0 版本而编写的，但现在经过重新设计以支持新的 0.1.0 API。

出于向后兼容的原因，我希望能够通过编译标志为旧库或新库构建 myapp。 myapp 的给定构建将加载到的内核将始终只有一个版本的库，在编译时已知。

问题

以后libfoo很有可能会再次更新。

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

2. 我知道可以直接在构建 CLI 上指定库名称。这会导致 myapp 要求完全那个版本，或者具有相同主要修订版的 lib 的更高版本仍然能够链接到它(例如 libfoo.所以.0.2.0)？我真的希望不必在每次发布新的次要版本时都更新每个依赖应用的构建。

3. 是否有更智能的方式以与应用程序无关的方式完成此任务？

引用资料

How do you link to a specific version of a shared library in GCC

Answer 1

您正在描述外部 库版本控制，其中应用是针对 libfoo.so.0、libfoo.so.1 等构建的. 文档 here .

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

这通常不是 Linux 上的正确技术，通过 symbol versioning 的魔力, 允许单个 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 的旧库运行，则应用程序将无法启动并出现明显错误。