为什么在Linux上NSS模块必须以.so.2结尾？

我已经为Red Hat Linux构建了一个名称服务交换模块

使用strace，我确定操作系统在不同的目录中查找库，但只查找扩展名为

.so.2

的文件（例如

libnss\u xxx.so.2

，其中

xxx

是服务名称）

为什么它不查找

.so

或

.so.1

库？是否有任何保证，它将来不会停止查找

.so.2

库，而开始查找

.so.3

库

EDIT：，表示

2

是“一个版本号，在接口更改时会递增”。 所以我想：

• NSS版本需要库的版本2
• 具有更新NSS的操作系统更新可能需要不同的版本号

---

有人能确认这是否属实吗？

so文件有两种类型：共享库（在编译时加载并扫描符号，在程序启动时再次加载并链接）和模块（在运行时加载并链接）。共享库的概念是，您的程序需要特定版本的库。此版本在编译时确定。编译程序后，即使安装了库的新（不兼容）版本，程序也应继续工作。这意味着新版本必须是不同的文件，因此旧程序仍然可以使用旧库，而新（或最近编译的）程序使用新版本

要正确使用此系统，您的程序必须以某种方式确保继续安装所需的库版本。这是分销包装系统的任务之一。包含程序的包必须依赖于库包的所需版本

然而，您似乎在谈论模块。那里的情况不同。它们没有这样的版本，因为ld.so（负责加载共享库）不是加载它们的那个。您的程序应该与这些模块捆绑在一起，以便模块版本始终与使用它们的程序兼容。这适用于大多数程序

---

但是，如果您的程序允许使用第三方模块，那么它就不起作用。因此，他们可以提出自己的版本控制系统。这似乎就是nss所做的（尽管我不熟悉）。这意味着他们已经定义了一个协议版本（目前为2），它指定了一个模块应该是什么样子：需要定义哪些符号，函数期望什么参数，诸如此类的事情。如果按照协议版本2创建模块，则应将模块命名为.so.2（因为这是他们检查支持的版本的方式）。如果他们创建了一个新的不兼容的协议3，他们将开始寻找。您的模块将不再被找到，这是一件好事，因为它也不支持新协议。

您的假设通常是正确的，只需稍加编辑：

• NSS版本需要接口版本为2的库的版本
• 具有更新NSS的操作系统更新可能需要不同的版本号

接口的版本不一定需要随库的版本而改变，即库的较新版本可能仍然提供相同的接口