为什么 boost 软件包库安装到 /usr/lib/x86_64-linux-gnu?

为什么 boost 软件包库安装到 /usr/lib/x86_64-linux-gnu?

跑步后

sudo apt-get install libboost-all-dev

在 ubuntu 14.04 amd64 桌面 (Trusty Tahr) 上,我发现所有的库都安装到了

/usr/lib/x86_64-linux-gnu/

代替

/usr/lib/

尽管所有标题仍安装在

/usr/include/

为什么会发生这种情况?

答案1

库软件包已制作成多架构,这意味着您可以在 amd64 计算机上同时安装 amd64 版本和 i386 版本。如果要安装库的 i386 版本,请在软件包名称后加上:i386。(例如,sudo apt-get install libboost-system1.54.0:i386

库软件包正在转向多架构,这样安装来自其他架构的软件包和运行为其他架构编译的程序会更加容易一些。

答案2

这是规范规定的。标头仍然是规范中未解决的问题。并且被视为超出范围,如来源未解决问题标题下

“设计

文件系统布局

为了在系统上无缝容纳多个 ELF ABI,每个 (soname,ABI) 对的库在文件系统上都必须具有唯一的路径。FHS 尝试针对 amd64 的情况解决此问题,方法是要求 /usr/lib 保留用于 32 位库,而 64 位库位于 /usr/lib64。这种设计有许多缺点:

这与任何未来的 ABI 更改都不向前兼容,这需要进一步的设计工作和对软件包的进一步修改才能处理新路径的添加。(事实上,这已经成为 MIPS 架构的一个问题,因为它同时使用三个不同的 ABI。)

amd64 架构在库打包中必须是特殊情况,因为它是唯一使用 /usr/lib64 而不是 /usr/lib 的架构。(两个预先存在的 64 位 Linux 移植,Alpha 和 IA-64,也使用 /usr/lib 作为其 64 位库。)这增加了不必要的复杂性。

它没有解决模拟用例,例如 qemu,如果 qemu arch 的软件包可以共同安装,则可以更好、更有效地与系统集成。

Debian 和 Ubuntu 当前使用的设计也失败了,因为 FHS 布局没有:

x86 和 x86-64 库的路径取决于系统本身是 32 位还是 64 位,因此在安装时翻译路径对于一般情况来说是不够的,因为某些库需要在二进制文件本身中嵌入插件路径。

Multiarch 试图解决所有这些问题,但需要一次性转换,方法是将库迁移到包含体系结构三元组作为路径一部分的子目录:

/lib/i386-linux-gnu /lib/x86_64-linux-gnu /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu”

来源

相关内容