hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: time for libio?


From: Marcus Brinkmann
Subject: Re: time for libio?
Date: Fri, 30 Nov 2001 07:11:42 +0100
User-agent: Mutt/1.3.23i

On Thu, Nov 29, 2001 at 05:04:31PM -0800, Thomas Bushnell, BSG wrote:
> The different library versions install different .so's, right?

No, they don't.  The failing case is exactly this:

Before libc update:
libc.so.0.2
libfoo.0 linked to libc.so.0.2
bar-1 linked to libfoo.0 and libc.so.0.2

After libc update:
libc.so.0.3
libc.so.0.2
libfoo.0 linked to libc.so.0.2
bar-1 linked to libfoo.0 and libc.so.0.2

Everything still works.
Now bar is recompiled with a new libc on the maintainers machine.

After bar is updated:
libc.so.0.3
libc.so.0.2
libfoo.0 linked to libc.so.0.2
bar-2 linked to libfoo.0 and libc.so.0.3

bar-2 will suck in libfoo.0 which suckes in libc.so.0.2, which means that
both C libraries are loaded.  Usually this results instantly in a
segmentation fault.

What did Debian do?  Debian used several tricks:
1. The dynamic linker had some built in magic to do the right thing and use
/lib/libc5-alt/ for binaries linked to old libc.
2. A libc5 compiler suite was provided.
3. All libraries had to be built twice, once against libc5, and once against
the new libc.  The name of the library compiled against the new libc had to
be changed (appending a "g"), libfoo0 would become libfoo0g, so the soname
would be different, and updates be forced via dpkg/apt, and the linker had
the right clues.
4. After a while, libc5 support was dropped.
5. When libfoo1 was released, the "g" suffix to the libraries name could be
dropped.

The problem is exactly that libraries depending on libc have to change their
soname as well.  As not all libraries update to a new soname fast, this has
to be done by the package maintainer.  Now even, many years after the Debian
GNU/Linux libc5 -> libc6 update, we still have libfoog packages, like
libpaperg.

> We do have the "library dependency soname problem": in principle we
> have to bump the soname on every library that includes a dependency on
> libc, when the libc soname bumps.

Indeed we have to.

> I think the problem is that once a library maintainer were to put a
> new version of the library up, and then a package gets installed that
> depends on the new version, every user--and build agent--gets the new
> library, and like a snowball, pretty much every package starts needing
> to be rebuilt.  But things work ok for users along the way--it's just
> that it's very hard to go back.

Things don't work, as the correct dependencies are not enforced by dpkg/apt
without the package maintainers cooperation.  This is a major effort.  It
took a year or so.  I don't expect that Debian is willing to go through all
this once or twice for us.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]