有两种类型的so文件：共享库(在编译时加载和扫描符号，在程序启动时再次加载并链接)和模块(在运行时加载和链接)。共享库的概念是，您的程序需要特定版本的库。此版本在编译时确定。一旦程序被编译，即使安装了新的(不兼容的)库版本，它也应该继续工作。这意味着新版本必须是不同的文件，因此旧程序仍然可以使用旧库，而新的(或最近编译的)程序使用新版本。
我为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是"每当接口更改时都会递增的版本号"。所以我想：
- NSS版本需要版本2的库
- 带有已更新NSS的操作系统更新可能需要不同的版本号
有人能确认这是否属实吗？
您的假设通常是正确的，只需进行一次小的编辑：
- NSS版本需要版本的库，接口版本为2
- 带有已更新NSS的操作系统更新可能需要不同的版本号
接口的版本不一定需要随库的版本而更改，即较新版本的库可能仍然提供相同的接口。
要正确使用此系统，您的程序必须以某种方式确保它所需的库版本将继续安装。这是分销包装系统的任务之一。包含程序的程序包必须依赖于所需版本的库程序包。
然而，您似乎在谈论模块。那里的情况有所不同。它们没有这样的版本，因为ld.so(负责加载共享库)不是加载它们的那个。您的程序应该与这些模块捆绑在一起，因此模块版本始终与使用它们的程序兼容。这适用于大多数程序。
但如果你的程序允许第三方模块，它就不起作用。因此，他们可以提出自己的版本控制系统。这似乎就是nss所做的(不过我并不熟悉)。这意味着他们已经定义了一个协议版本(目前为2)，它指定了模块应该是什么样子：需要定义哪些符号，函数期望什么参数，诸如此类。如果您按照协议的版本2创建一个模块，您应该将模块命名为.so.2(因为这是他们检查您支持的版本的方法)。如果他们创建了一个新的不兼容协议3，他们将开始寻找.so.3。您的模块将不再被找到，这是一件好事，因为它也不支持新协议。