x86_64-linux-gnu？

跑完之后

sudo apt-get install libboost-all-dev

在ubuntu 14.04 amd64桌面（Trusty Tahr）上，我发现所有的lib都安装在

/usr/lib/x86_64-linux-gnu/

代替

/usr/lib/

虽然所有标头仍然安装在

/usr/include/

为什么会这样？

库包已经多了，这意味着您可以在amd64计算机上同时安装amd64版本和i386版本。如果要安装库的i386版本，请将软件包名称后缀为:i386 。（例如， sudo apt-get install libboost-system1.54.0:i386 ）

库包正在转向成为multiarch，因此从其他体系结构安装包并运行为其他体系结构编译的程序会更容易一些。

这是按规格。标题仍然是规范中尚未解决的问题。并且在未解决问题标题下的来源中指出了超出范围

“设计

文件系统布局

为了在系统上无缝容纳多个ELF ABI，每个（soname，ABI）对的库必须在文件系统上具有唯一的路径。 FHS试图通过要求/ usr / lib保留用于32位库，64位库位于/ usr / lib64中来解决amd64情况。这种设计有许多缺点：

这与以后的任何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“

资源