Linux 可以容纳共享库的多个版本，但是包含文件呢？

Question

我试图了解如何在 Linux 下管理共享库版本，以及在配置和编译程序时这些版本如何与不同版本的包含文件交互。

我知道一个系统可以有多个版本的共享库(.so 文件)，文件名中 libxxx.so 之后的第一个版本号不同，并且不同的程序可能与同一库的不同版本链接。库的新版本(.so.# 已更改)通常与以前的版本不兼容。 (第一个之后的版本号是不影响其兼容性的次要库更改)。

如果我正在编译(或重新编译)一个与旧版本库链接的旧程序，并且如果我的系统上同时拥有旧库和新库，似乎没有管理多个版本的机制与每个库版本关联的包含文件。因此，即使我有旧版本的库可用，但没有要链接到的旧版本的包含文件，我真的无法重新编译该程序。是真的吗？

如果是这样，那么支持多个库版本的值(value)似乎值得怀疑。这个想法必须是旧版本库的唯一用户是在旧版本是当前版本时编译的程序，并且任何程序都不应该被重新编译，除非它链接的所有库的所有版本都是最新版本的系统上安装的那些库。一旦安装了新版本的库，所有使用旧版本的程序都无法再编译(除非使用新库更新到新版本)。对吧？

或者，人们是否通常会为安装的每个库的每个版本保留一个单独的包含文件子目录，以便可以使用适当的包含文件和库版本重新编译程序？

Answer 1

包含文件的处理方式不同于共享库:

• 有了共享库，开发包在链接时会使用一个名称，这是一个指向具有特定soname 文件的符号链接(symbolic link)(名称加版本)。链接后，程序会引用该文件，每当运行该程序时都会使用该文件。

• 包含文件可以通过包含路径的-I 选项来区分。当一个库有多个有用版本时，一些开发人员可能会使用不同的目录名称来打包这些版本以保存相关的头文件。这样，在编译时仅更改 -I 选项就可以使构建脚本能够使用特定版本的 header 。但与共享库不同的是，头文件仅在构建使用库的程序时使用。