I was building a new version of Spice within an LXC container, mostly for experimentation. However, one strange thing that I encountered was that make install installed libspice-server.so.1.9.0 into /usr/lib. The result was a nasty segfault when using the QXL driver because of the fact that libspice-server.so.1.8.0 from the repositories was located in /usr/lib/x86_64-linux-gnu, which has a higher precedence in ldconfig. So, it was dynamically linking the older version of the library with the newer code -- no good.

Anyway, this got me thinking: Other than ldconfig ordering (which I don't think has anything to do with it) is there a functional or philosophical difference between placing a library in /usr/lib versus placing a library in /usr/lib/{x86_64,i386}-linux-gnu?

I understand the need for separate /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu directories due to Debian not utilizing the /usr/lib /usr/lib32 hierarchy used by some other distros. But, do libraries that are directly in /usr/lib have some special significance, or it simply for backwards compatibility, perhaps?

2 Answers 2


In Debian and Ubuntu, and indeed the FHS, /usr/lib and variants are "owned" by the vendor. In this case, that means your distribution. You should not be placing files there yourself at all. Of course you can do as you like, but tooling (such as dpkg) will just overwrite files you place there without prompting, because the system by design considers these spaces for distribution packages only. Your system is yours to break as you wish, but you also get to keep the pieces :-)

The space reserved for the system owner/administrator to place extra system-wide libraries is /usr/local/lib. This is in the FHS, so should be available and configured across all standards-respecting distributions. Upstream software should have make install place libraries there by default.

...is there a functional or philosophical difference between placing a library in /usr/lib versus placing a library in /usr/lib/{x86_64,i386}-linux-gnu?

Distribution packages that use /usr/lib can't have different architectures installed at once (such as i386 vs. amd64), which as others have pointed out is useful for desktops running both 32-bit and 64-bit software, and for developers running code built for other architectures by emulation. This is the sole reason for the multiarch subdirectories.

The same applies to libraries you install yourself. Whether you do that in /usr/lib or /usr/local/lib, you won't be able to have multiple architectures supported concurrently. You can always add multiarch paths like /usr/local/lib/{x86_64,i386}-linux-gnu to /etc/ld.so.conf.d/ to enable that of course.


You are right, in a traditional system all libraries were installed in /usr/lib. As you already mentioned, the fact that users like to execute 32-bit binaries on 64-bit platforms is one of the reasons to separate libraries by their architecture. This approach is known as Multiarch (at least in the Debian world).

In addition, developers like to install libaries of other architectures (like ARM) to cross-compile their applications.

The FHS recommends to put 32-/64-bit libaries into the folders /usr/lib{32,64}. This approach is kind of inflexible as there is no support for other architectures (e.g. ARM). There even exist multiple 64-bit ABIs which are not compatible with each other and would end up in the same folder.

Further information:

  • 2
    Yep, I had already seen the FHS and Multiarch specs ;) However, the real question was: why do libraries still exist in both /usr/lib and /usr/lib/*-linux-gnu? Is it a technical reason or a matter of preference/ideology? Does it depend on the origin of the source (i.e., a build of Red Hat-origin would get placed in /usr/lib versus a Debian-origin build placed in /usr/lib/*-linux-gnu), perhaps?
    – Chuck R
    Dec 10, 2014 at 12:15
  • 1
    I am also interested on this. Should we install our compiled libraries on /usr/lib/$(DEB_HOST_MULTIARCH) or we must do it on /usr/lib? Can we replace the libraries already in the multiarch folder for new compiled ones? Jan 16, 2017 at 6:14
  • 1
    @BernardoRamos, One thing that I noticed, The libraries installed to /usr/lib directly belongs to *:amd64 packages (natives packages, I have 64bit installation), I have checked only few, and none has *:i386 package (foreign arch) with same name. So those libraries only exist in native architecture no need to move them into ARCH specific folder. I didn't verify Debian policy yet, that's why I wrote this as a comment till I find a reference.
    – user.dz
    Jan 16, 2017 at 8:13

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.