关于Ubuntu从Focal到Jammy版本中libc6库版本命名方案变更的咨询

你好，针对你提出的libc6库命名变更问题，我整理了相关细节和解答：

一、命名变更的原因 #

这个调整其实来自上游glibc（也就是Ubuntu里libc6包对应的核心项目）的设计更新：从Focal搭载的glibc 2.31到Jammy的glibc 2.35，项目规范做了针对性调整：

• 带完整版本号的文件（比如libdl-2.31.so）现在作为内部实现文件存在，主要供系统内部调用或编译场景使用
• 对外提供的动态链接接口统一改用只带主版本号的soname（比如libdl.so.2），这是因为glibc的主版本号代表了稳定的ABI（应用二进制接口）——只要主版本号不变，所有依赖该库的应用程序都能兼容运行，无需关注次版本号的迭代更新。这种做法能大幅简化系统的版本依赖管理，避免因次版本更新导致不必要的兼容性问题。

二、是否会推广到所有Ubuntu库？ #

这个变更并不是Ubuntu的独立决策，而是跟随上游glibc的规范调整。对于其他库来说，是否采用类似的命名方式完全取决于各自的上游项目维护团队，Ubuntu通常会遵循上游的设计，不会自行修改库的命名规则。所以并不会所有库都统一改成这种模式，具体要看每个库的上游规范。

三、能否恢复旧的命名惯例？ #

其实不需要刻意恢复，而且也没有全局恢复的官方方案：

1. 旧的带完整版本号的库文件依然存在于系统中（比如Jammy里的/usr/x86_64-linux-gnux32/lib64/libdl-2.35.so），只是在包的文件列表里优先展示了对外的soname链接；
2. 如果你的应用确实需要指定链接到特定次版本的库，可以在编译或运行时直接指定该文件的完整路径，但不建议这么做——因为glibc的主版本号已经保证了ABI兼容性，次版本更新都是向后兼容的，强行绑定次版本会导致未来系统更新时出现兼容性风险；
3. 目前没有专门的包或系统设置可以全局恢复旧的命名模式，因为这是上游的设计变更，Ubuntu不会提供逆向修改的选项。

举个实际的对比：

• Focal中的/usr/x86_64-linux-gnux32/lib64/libdl-2.31.so是实际库文件，同时系统也会创建libdl.so.2的软链接指向它
• Jammy中的/usr/x86_64-linux-gnux32/lib64/libdl.so.2是软链接，指向实际存在的libdl-2.35.so文件

备注：内容来源于stack exchange，提问作者Eswar Reddy