6

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

/usr/lib/x86_64-linux-gnu/

instead of

/usr/lib/

Although all the headers are still installed into

/usr/include/

Why does this happen?

Improve this question
2
  • 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, 2014 at 0:44
  • @saiarcot895 Yeah, I'll correct it.
    – WiSaGaN
    Apr 18, 2014 at 0:46

2 Answers 2

Reset to default
8

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.

Improve this answer
4
  • 3
    This should be the spec: wiki.ubuntu.com/MultiarchSpec
    – WiSaGaN
    Apr 18, 2014 at 1:25
  • 2
    This is the spec
    – Elder Geek
    May 13, 2014 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, 2015 at 14:07
  • @TomášZato: Edited.
    – saiarcot895
    Sep 29, 2015 at 16:21
2

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

"Design

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"

source

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .