Packaging: /usr/lib vs. /usr/lib/*-linux-gnu
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/
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/-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/-linux-gnu to /etc/ld.so.conf.d/ to enable that of course.
Difference between /usr/lib and /usr/lib/x86_64-linux-gnu folders
I’m not very familiar with the linux root folders. I have an Ubuntu 18.04 machine. What is the difference between the two folders /usr/lib and usr/lib/x68_64-linux-gnu . I ask this since my boost .so files are of different versions in the two folders.
1 Answer 1
/usr/lib/x86_64-linux-gnu is the multiarch folder for libraries built for 64-bit x86 on Linux using the GNU C library. /usr/lib is the historical folder for libraries built for the system; you’ll still find libraries there because quite a few packages don’t follow the multiarch spec.
The Boost packages in Ubuntu ship their libraries in the multiarch folder, so the libraries in /usr/lib are presumably from a source other than Ubuntu, or from an older version of the package that’s still installed.
Thanks! Is it safe for me to remove the boost related .so files in the usr/lib/x68_64-linux-gnu folder, and copy the boost related .so files from /usr/lib to that folder?
Yes, in the /usr/lib folder, I have boost 1.72 version, while in the /usr/lib/x68_64-linux-gnu folder, I have 1.65 version. I am running into dependency conflicts for certain package installations because of this.
You shouldn’t manually remove packaged files; /usr (apart from /usr/local ) is managed only by the package manager. I suggest you ask a new question to explain the dependency conflicts you’re running into, you’ll get more useful answers that way.
After upgrading to Debian 12, duplicated files in /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/
I just upgraded my system from Debian 11 to 12, by following this guide from cyberciti. This system has been kept up-to-date for more than 9 years, so it has been through at least 4 major upgrades (Debian 7 or 8 to 12 today). During the first run of apt upgrade —without-new-pkgs , I had an error about libudev (sadly I forgot to keep the output from the command), that I fixed by removing 2 files:
$ rm /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.1.6.5 I was able to finish the upgrade and reboot. By performing further investigation, it looks like my system has some other duplicated libraries:
$ dpkg --search /lib/x86_64-linux-gnu/perl/ /usr/lib/x86_64-linux-gnu/perl/ dpkg-query: no path found matching pattern /lib/x86_64-linux-gnu/perl/ libperl5.36:amd64: /usr/lib/x86_64-linux-gnu/perl $ ls -ld /lib/ /lib/x86_64-linux-gnu/ /usr/ /usr/lib/ /usr/lib/x86_64-linux-gnu/ drwxr-xr-x 84 root root 4.0K Jul 5 21:05 /lib// drwxr-xr-x 78 root root 96K Jul 5 21:05 /lib/x86_64-linux-gnu// drwxr-xr-x 12 root root 4.0K Jul 5 20:32 /usr// drwxr-xr-x 84 root root 4.0K Jul 5 21:05 /usr/lib// drwxr-xr-x 78 root root 96K Jul 5 21:05 /usr/lib/x86_64-linux-gnu// - Is it normal to have duplicated libraries in /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/
- Can I rely on the output of dpkg —search and delete the paths that show no path found … ? Or can some tool help me clean this mess?
- What events on my system could have made this possible?
Update: actually it looks like there 2 directories are identical:
$ ls -lh /lib/x86_64-linux-gnu/test.ignore /usr/lib/x86_64-linux-gnu/test.ignore ls: cannot access '/lib/x86_64-linux-gnu/test.ignore': No such file or directory ls: cannot access '/usr/lib/x86_64-linux-gnu/test.ignore': No such file or directory $ touch /lib/x86_64-linux-gnu/test.ignore $ ls -lh /lib/x86_64-linux-gnu/test.ignore /usr/lib/x86_64-linux-gnu/test.ignore -rw-r--r-- 1 root root 0 Jul 5 22:14 /lib/x86_64-linux-gnu/test.ignore -rw-r--r-- 1 root root 0 Jul 5 22:14 /usr/lib/x86_64-linux-gnu/test.ignore But I don’t understand how it works. And now I know that I must not delete files from /lib/x86_64-linux-gnu/ because it would delete files in /usr/lib/x86_64-linux-gnu/ too.