multilib followup: caution about remnant shared library files
Here's a cautionary heads up on the transition from ordinary to multilib Debian.
I run Debian Wheezy amd64. Some 32 bit applications are installed, and
somehow I came to a point where ia32libs wanted to update and
transition me to a multilib setup. I'm still trying to figure out if
that happened because I accidentally had sid enabled, or not, but I
decided to go ahead and see what happens. The big block of 32bit
support libraries from ia32-libs is replaced by a lot fo i386
packages.
It has been a little interesting to rebuild some local packages, I
think most of that will work itself out. There are good docs on
re-writing debian packaging for multilib.
But today I found about a serious problem I want to warn any/everybody
about. The multilib packages will replace files from /usr/lib with
files that go into /usr/lib/x86_64-linux-gnu or
/usr/lib/i386-linux-gnu. If all goes well, that's the end of it.
However, some packages don't remove their own files (or, at least,
they don't get it done for me). In the packaging, there are multilib
instructions, to assure the removal of files from /usr/lib when the
new are installed in the new folders. However, some packages
malfunction, and so you are left with the old shared library files. I
was having a devil of a time building some packages because the build
system was finding libraries that I thought had been removed in
/usr/lib.
I used a handy Debian tool "cruft" to survey the situation, and here
are some of the "abandoned" library files that were left in /usr/lib:
libanl-2.11.2.so
libanl.so.1
libBrokenLocale-2.11.2.so
libBrokenLocale.so.1
libcidn-2.11.2.so
libcidn.so.1
libcrypt-2.11.2.so
libcrypt.so.1
libgcc_s.so.1
libmemusage.so
libnss_compat-2.11.2.so
libnss_compat.so.2
libnss_dns-2.11.2.so
libnss_dns.so.2
libnss_files-2.11.2.so
libnss_files.so.2
libnss_hesiod-2.11.2.so
libnss_hesiod.so.2
libnss_nis-2.11.2.so
libnss_nisplus-2.11.2.so
libnss_nisplus.so.2
libnss_nis.so.2
libpcprofile.so
libresolv-2.11.2.so
libresolv.so.2
libSegFault.so
libthread_db-1.0.so
libthread_db.so.1
Here's what goes wrong when those files are found during the package
build process. The linker notices shared files in /lib or /usr/lib,
but it can't find shlib dependency information on those in /var/
hierarchy (because that hierarchy now shows they are in
/usr/lib/x86_64-linux-gnu.
If you try to compile a package, you will recognize the problem if the
error says
error: no dependency information found for /lib/libnsl.so.1
and it is pointing to a file that is in there, but
$ dpkg -S /lib/libnsl.so.1
is not owned by a package, and then you notice that there is a newer
version of libnsl.so in /usr/lib/x86_64-linux-gnu.
I'm pretty sure this is right, but I can't rule out the possibility
that some other thing that happened in apt-get or synaptic caused
this. I also found a big chunk of python numpy stuff was "orphaned"
by package updates.
As I mentioned, the cruft package from Debian was a big help in
finding the problem. All I did was install the package, then
$ cd /tmp
$ sudo /usr/sbin/cruft -d /lib -r report-lib
$ sudo /usr/sbin/cruft -d /usr/lib -r report-usrlib
that cranks out the reports that show whether files are missing or not
valid members of deb packages.
--
Paul E. Johnson
Professor, Political Science Assoc. Director
1541 Lilac Lane, Room 504 Center for Research Methods
University of Kansas University of Kansas
http://pj.freefaculty.org http://quant.ku.edu
Reply to: