我正在 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？
我理解由于 Debian 没有利用其他一些发行版使用的层次结构，因此需要单独的/usr/lib/i386-linux-gnu和/usr/lib/x86_64-linux-gnu目录/usr/lib /usr/lib32。但是，直接在/usr/lib其中的库是否具有某些特殊意义，或者仅仅是为了向后兼容？
在 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 位软件的台式机以及为运行构建的代码的开发人员很有用其他架构通过仿真。这是 multiarch 子目录的唯一原因。
这同样适用于您自己安装的库。无论您在/usr/lib或 中执行此操作/usr/local/lib，您都无法同时支持多个体系结构。您可以随时添加multiarch路径类似/usr/local/lib/{x86_64,i386}-linux-gnu，以/etc/ld.so.conf.d/使那当然。