After running

sudo apt-get install libboost-all-dev

on ubuntu 14.04 amd64 desktop (Trusty Tahr), I found that all the libs are installed into


instead of


Although all the headers are still installed into


Why does this happen?

  • According to dpkg -L libboost-system1.54.0 (and other boost libraries), I think the libraries are installed to /usr/lib/x86_64-linux-gnu. – saiarcot895 Apr 18 '14 at 0:44
  • @saiarcot895 Yeah, I'll correct it. – WiSaGaN Apr 18 '14 at 0:46

The library packages have been made multiarch, meaning that you can simultaneously install both the amd64 version and the i386 version on an amd64 computer. If you want to install the i386 version of a library, suffix the package name with :i386. (For example, sudo apt-get install libboost-system1.54.0:i386)

Library packages are shifting towards becoming multiarch, so that it is a little easier to install packages from other architectures and run programs compiled for other architectures.

  • 3
    This should be the spec: wiki.ubuntu.com/MultiarchSpec – WiSaGaN Apr 18 '14 at 1:25
  • 2
    This is the spec – Elder Geek May 13 '14 at 2:52
  • While you're at it, couldn't you please extend the answer with "How to install 32bit boost?" It's not directly the answer to question but it would help a lot of google visitors, such as me. – Tomáš Zato Sep 29 '15 at 14:07
  • @TomášZato: Edited. – saiarcot895 Sep 29 '15 at 16:21

This is by spec. The headers are still an unresolved issue in the spec. and considered out of scope as noted in the source under the heading of Unresolved Issues


Filesystem layout

In order to seamlessly accommodate more than one ELF ABI on a system, the library for each (soname,ABI) pair must have a unique path on the filesystem. The FHS attempts to address this for the amd64 case by requiring that /usr/lib be reserved for 32-bit libraries, with 64-bit libraries located in /usr/lib64. This design has a number of shortcomings:

This is not forwards-compatible with any future ABI changes, which would require further design work and further modification of packages to handle the addition of new paths. (Indeed, this is already a concern for the MIPS architecture which has three distinct ABIs in use in parallel.)

The amd64 architecture must be special-cased in the library packaging, as the only architecture that uses /usr/lib64 instead of /usr/lib. (Two pre-existing 64-bit Linux ports, Alpha and IA-64, also used /usr/lib for their 64-bit libs.) This is unnecessary added complexity.

It does not address emulation use cases, such as qemu, which could integrate much better and more efficiently with the system if the packages for a qemu arch were co-installable.

The current design used by Debian and Ubuntu also fails on a key point where the FHS layout does not:

The path for x86 and x86-64 libraries varies depending on whether the system is natively 32-bit or 64-bit, so translating paths at install time is insufficient for the general case because some libraries need to embed plugin paths in the binaries themselves.

Multiarch seeks to address all of these issues, at the expense of a one-time transition, by migrating libraries to subdirectories that include the architecture triplet as part of the path:

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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.