我为Red Hat Linux构建了一个名称服务交换模块。为什么NSS模块不得不在Linux上以.so.2结尾？
使用strace的，我已经确定OS会在不同的目录库中，但仅适用于具有扩展.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。你的模块将不再被发现，这是一件好事，因为它也不会支持新的协议。