我正在 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有一些特殊意义，或者只是为了向后兼容，也许？
答案1
在 Debian 和 Ubuntu 以及 FHS 中，/usr/lib变体由供应商“拥有”。在这种情况下，这意味着您的发行版。您根本不应该自己将文件放在那里。当然，您可以随心所欲地做，但工具（如 dpkg）只会在没有提示的情况下覆盖您放在那里的文件，因为系统在设计上将这些空间仅用于发行版软件包。您的系统由您自己随意破坏，但您也可以保留这些碎片 :-)
为系统所有者/管理员保留的空间用于放置额外的系统范围库/usr/local/lib。它位于 FHS 中，因此应该在所有遵循标准的发行版中可用且配置。上游软件应该make install默认将库放置在那里。
...将库放在 /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/
答案2
您说得对，在传统系统中，所有库都安装在 中/usr/lib。正如您之前提到的，用户喜欢在 64 位平台上执行 32 位二进制文件，这是根据架构区分库的原因之一。这种方法称为多架构（至少在 Debian 世界中）。
此外，开发人员喜欢安装其他架构（如 ARM）的库来交叉编译他们的应用程序。
FHS 建议将 32/64 位库放入文件夹中/usr/lib{32,64}。这种方法不太灵活，因为不支持其他架构（例如 ARM）。甚至存在多个彼此不兼容的 64 位 ABI，它们最终会放在同一个文件夹中。
更多信息：