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