Linux程序动态加载共享对象时的版本文件名选择问题

首先明确结论：你应该优先加载libfoobar.so.0，而不是libfoobar.so或者完整的libfoobar.so.0.0.0，而且仅尝试加载libfoobar.so.0失败就退出，在绝大多数场景下是足够的。

下面详细解释原因：

共享对象的版本命名规则 #

Linux下的共享库命名遵循一套行业标准：

• libfoobar.so：这是开发用的符号链接，通常指向系统中最新的主版本库（比如libfoobar.so.0），主要给编译链接阶段用，运行时环境不一定会提供（就像你提到的另一发行版就没有这个文件），所以完全不能作为运行时加载的可靠目标。
• libfoobar.so.0：这是主版本号文件（或指向完整版本的符号链接），主版本号代表ABI（应用二进制接口）兼容的版本组。只要是主版本号相同的库——比如libfoobar.so.0.0.0、libfoobar.so.0.1.0——它们的接口都是二进制兼容的。程序加载这个主版本文件，就能自动使用系统中该主版本下的最新库文件，灵活性拉满。
• libfoobar.so.0.0.0：这是完整版本文件，包含主、次、修订三个版本号。直接加载它的话，一旦系统更新到同主版本的更高次版本（比如libfoobar.so.0.1.0），你的程序就会找不到这个特定文件名的库，直接加载失败，完全没有适配性可言。

关于加载策略的补充 #

仅尝试加载libfoobar.so.0失败就退出是足够的，理由如下：

• 如果系统中存在libfoobar.so.0.0.0，那几乎肯定会有libfoobar.so.0的符号链接——这是Linux发行版打包共享库的标准操作，不会少。
• 如果libfoobar.so.0不存在，说明系统根本没安装该ABI兼容的库版本，就算你硬去尝试加载libfoobar.so.0.0.0，要么找不到文件，要么加载后也会因为系统环境差异触发兼容性问题，这种情况下退出是最合理的选择。

当然，如果你想做极端场景的兜底，也可以先试libfoobar.so.0，失败后再尝试libfoobar.so.0.0.0，但这属于冗余操作，正规发行版的环境下，主版本号的文件已经足够可靠。

内容的提问来源于stack exchange，提问作者megagrump