logo标签列表

包装：/usr/lib vs. /usr/lib/*-linux-gnu

packaging
我正在一个LXC容器中构建Spice的新版本，主要是为了实验。然而，我遇到的一个奇怪问题是，make install将libspice-server.so.1.9.0安装到了/usr/lib目录下。结果是，在使用QXL驱动时出现了一个令人讨厌的段错误，因为仓库中的libspice-server.so.1.8.0位于/usr/lib/x86_64-linux-gnu目录下，而这个目录在ldconfig中具有更高的优先级。所以，它在动态链接时将旧版本的库与新代码进行了链接，这是不好的。
无论如何，这让我想到了一个问题：除了ldconfig的顺序（我认为与此无关）之外，将库放在/usr/lib和将库放在/usr/lib/{x86_64,i386}-linux-gnu之间是否存在功能或哲学上的区别？
我理解为什么需要分开的`/usr/lib/i386-linux-gnu`和`/usr/lib/x86_64-linux-gnu`目录，因为Debian没有使用其他发行版中使用的`/usr/lib`和`/usr/lib32`层次结构。但是，直接放在`/usr/lib`中的库是否具有特殊意义，还是只是为了向后兼容性呢？
2个回答
在Debian和Ubuntu中，以及事实上的FHS中，/usr/lib和其变种是由供应商“拥有”的。在这种情况下，这意味着您的发行版。您不应该自己将文件放在那里。当然，您可以按照自己的喜好去做，但是工具（如dpkg）会在没有提示的情况下覆盖您放置在那里的文件，因为系统设计上认为这些空间仅用于分发软件包。您可以随心所欲地破坏您的系统，但也要自己承担后果 :-)
为系统所有者/管理员预留的空间来放置额外的系统范围库是/usr/local/lib。这在FHS中规定，因此应该在所有遵守标准的发行版中都可用和配置。上游软件应默认将库安装到这里。

...在将库放置在/usr/lib与将库放置在/usr/lib/{x86_64,i386}-linux-gnu之间是否存在功能或哲学上的区别？

分发使用`/usr/lib`的软件包无法同时安装不同架构（例如i386和amd64），正如其他人指出的那样，这对于同时运行32位和64位软件的桌面以及通过模拟运行为其他架构构建的开发人员很有用。这就是多架构子目录存在的唯一原因。
同样适用于您自己安装的库。无论您将其安装在`/usr/lib`还是`/usr/local/lib`，您都无法同时支持多个架构。当然，您可以始终添加类似于`/usr/local/lib/{x86_64,i386}-linux-gnu`的多架构路径到`/etc/ld.so.conf.d/`以启用该功能。

你是对的，在传统系统中，所有的库都安装在 /usr/lib 中。正如你已经提到的，用户喜欢在 64 位平台上执行 32 位二进制文件的事实是将库按其架构分离的原因之一。这种方法被称为Multiarch（至少在 Debian 的世界中是这样）。

此外，开发人员喜欢安装其他架构（如 ARM）的库来交叉编译他们的应用程序。

FHS 建议将 32/64 位库放入文件夹 /usr/lib{32,64} 中。这种方法有点不灵活，因为不支持其他架构（例如 ARM）。甚至存在多个不兼容的 64 位 ABI，它们最终会出现在同一个文件夹中。

更多信息：

2是的，我已经看过了FHS和Multiarch规范；）然而，真正的问题是：为什么库文件仍然同时存在于/usr/lib和/usr/lib/-linux-gnu目录下？这是一个技术原因还是偏好/意识形态的问题？这是否取决于源代码的来源（例如，Red Hat构建的程序会放置在/usr/lib目录下，而Debian构建的程序会放置在/usr/lib/-linux-gnu目录下）呢？ - Chuck R
1我对此也很感兴趣。我们应该将编译好的库安装在 /usr/lib/$(DEB_HOST_MULTIARCH) 还是 /usr/lib 上？我们能否用新编译的库替换多架构文件夹中已有的库？ - Bernardo Ramos
1@BernardoRamos，有一件事我注意到了。安装在/usr/lib目录下的库文件直接属于*:amd64包（本地包，我使用的是64位安装），我只检查了几个，没有一个同名的*:i386包（外部架构）。所以这些库文件只存在于本地架构中，无需将它们移动到特定架构的文件夹中。我还没有验证Debian政策，所以我写成了评论形式，等我找到参考资料后再确认。 - user.dz