我已经为 Red Hat Linux 构建了一个名称服务切换模块。
使用 strace，我确定操作系统在各种目录中查找库，但仅查找具有扩展名的文件.so.2 （例如libnss_xxx.so.2，xxx服务名称在哪里）
为什么它不寻找.so或.so.1图书馆？是否有任何保证它不会停止寻找图书馆并在未来.so.2开始寻找图书馆？.so.3
编辑：http ://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html说这2是“每当界面更改时都会增加的版本号”。所以我猜：
有人可以确认这是否属实吗？
您的假设通常是正确的，只需稍作修改：
接口的版本不一定需要随着库的版本而改变，即更新版本的库可能仍然提供相同的接口。
so 文件有两种类型：共享库（在编译时加载和扫描符号，在程序启动时再次加载和链接）和模块（在运行时加载和链接）。共享库的想法是您的程序需要某个版本的库。此版本在编译时确定。程序编译后，即使安装了新的（不兼容的）库版本，它也应该继续工作。这意味着新版本必须是不同的文件，因此旧程序仍然可以使用旧库，而较新（或最近编译的）程序使用较新版本。
为了正确使用这个系统，你的程序必须以某种方式确保它需要的库版本将继续安装。这是分销包装系统的任务之一。包含您的程序的包必须依赖于所需版本的库包。
但是，您似乎在谈论模块。那里的情况有所不同。它们不带有这样的版本，因为 ld.so （负责加载共享库）不是加载它们的那个。您的程序应该与这些模块捆绑在一起，因此模块版本始终与使用它们的程序兼容。这适用于大多数程序。
但如果您的程序允许第三方模块，它就不起作用。因此，他们可以提出自己的版本控制系统。这似乎是 nss 所做的（不过我不熟悉它）。这意味着他们已经定义了一个协议版本（目前为 2），它指定了一个模块应该是什么样子：需要定义哪些符号，函数期望什么参数，这些东西。如果您创建一个遵循协议版本 2 的模块，您应该将您的模块命名为 .so.2（因为这是他们检查您支持的版本的方式）。如果他们创建了新的不兼容协议 3，他们将开始寻找 .so.3。您的模块将不再被找到，这是一件好事，因为它也不支持新协议。