Re: multilib followup: caution about remnant shared library files
+++ Steve Langasek [2013-01-11 00:13 -0800]:
> Hi Paul,
>
> On Fri, Jan 11, 2013 at 12:19:38AM -0600, Paul Johnson wrote:
Paul. 'multilib' is actually something (a bit) different.
You mean 'multiarch' throughout.
> > 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.
>
>
> These files are all from glibc. The glibc package has never been installed
> to /usr/lib: it installs to /lib. So what you have here is a local install
> of eglibc on your disk, not installed by Debian. (It's also a version of
> glibc, 2.11.2, which was not included in any stable Debian release.) So
> this isn't something that Debian should have handled for you as part of an
> upgrade.
You may be right steve, but I've seen a similar issue in fresh
chroots. I haven't yet got to the bottom of exactly what was going on,
but it's mentioned here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696267
Talking about (e)glibc headers being found in /usr/include:
-------
This has accidentally worked in the past (e.g in the quantal toolchain
bootstrap) because libc6-dev-i386 puts predefs.h into
/usr/include/bits/ (or at least leaves it there - this package owns
the directory - but nothing owns the files inside according to dpkg -
this should probably be the subject of another bug).
------
So I've seen evidence that glibc gets installed to plain non-multiarch
paths and then files get left there on package removal. Or something.
I've not yet spent the time to get to the bottom of it. Now of course
I was building toolchains so can't completely rule out a build
installing libc things in / but I don't think that was it as I was
still on stage1 of gcc so no glibc build had been run sfaik.
I must admit I don't know how dpkg can 'lose' files like this - I
thought it was very difficult to make that happen.
Just a data point.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: