Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]
Hi!
>>>>> Marcus Brinkmann writes:
MB> On Sun, Dec 27, 1998 at 10:35:38PM -0600, Gordon Matzigkeit
MB> wrote:
MB> We would then have libc0.2, libc0.3, libc0.4 etc packages, and
MB> binary packages depending on them. We would only maintain one set
MB> of development packages. Can you explain the drawbacks of this
MB> simple solution?
Maintaining only one set of development packages is fine, but we still
should ensure some kind of backwards compatibility, which is what my
proposal was aimed at.
MB> 2) A second reason, which is actually a flaw (but how serious?)
MB> in my proposal is when lib packages are not bumped in the soname:
MB> Consider the following linking:
<---- bash
glibc 0.2 v
<---- ncurses 3.4
MB> But when ncurses 3.4 gets recompiled with a new libc:
glibc 0.2 <---- bash
v
glibc 0.3 <---- ncurses 3.4
MB> ... and two different shlibs are in action for the same binary
MB> (is my model actually true? I am just guessing).
Yes, this is what happens.
MB> This can be bad, and it leads to segfaults with libc5 and
MB> libc6. I don't know if it works for two different libc6 versions,
MB> but it does not work for libc5/libc6.
It will not work in this situation either, because libc.so.0.2 and
libc.so.0.3 are incompatible. If they were compatible, there would be
no need to change the soname in the first place.
MB> I think if it is worth a try. If it turns out that we can't do it
MB> this way, we have to fall back to your more complex solution (or
MB> anything else what we come up with).
I already know that it won't work this way. I'm sure that we can come
up with a good solution in advance, especially with the prior work
that the Debian GNU/Linux people had to do.
MB> I think the main point are above. I append parts of a short
MB> document, "/usr/doc/debian-policy/libc6-migration.txt".
Hrm. I've browsed this file, and it just seems to confirm my
suspicions. Okay, so scratch my original proposal... it was
misguided. Here's my next attempt:
As you said, the basic problem occurs when a library's soname doesn't
change after one of its dependencies' soname changes. For example,
libncurses.so.4 is linked against libc.so.0.2. Then, a different
libncurses.so.4 is linked against libc.so.0.3.
There is nothing really sane that can be done in this situation,
because programs that depend on libncurses.so.4 might themselves
depend on either of the libc's.
The best that people can hope for is to stretch the dynamic linker, so
that multiple libncurses.so.4's can reside on the same system. So, we
would have a /lib/libc0.2-compat directory, a /lib/libc0.3-compat
directory, and so on.
This is what the Debian GNU/Linux people did.
The better solution is to change libncurses' soname when we start
linking it against different dependencies. If the libncurses that was
linked against libc.so.0.2 had a soname of `libncurses.so.4-0.2', and
the libc.so.0.3 version had a soname of `libncurses.so.4-0.3', then
everything would be fine. The bash binary would depend on either
`libncurses.so.4-0.2 and libc.so.0.2' or `libncurses.so.4-0.3 and
libc.so.0.3', which would all have distinct filenames, and there would
be no ambiguity.
Now, for development packages, we would make libc0.2-dev conflict with
libc0.3-dev. Then, libncurses4-0.2-dev would depend on libc0.2-dev,
libncurses4-0.3-dev on libc0.3-dev, and everybody is happy again.
Here is a graphic for the above situation:
<---- bash (compiled with libc0.2-dev and libncurses4-0.2-dev)
libc0.2 v
<---- libncurses4-0.2
on the same system, we might also have:
<---- mc (compiled with libc0.3-dev and libncurses4-0.3-dev)
libc0.3 v
<---- libncurses4-0.3
This is one thing about the Hurd: sonames can be completely
arbitrary... no program relies on their contents. ld.so only cares
about finding exact matches for a soname, and ld attaches whatever
soname you like to the library.
BTW, I vaguely remember a discussion on one of the glibc lists, in
which it was proposed that ld derive a shared library's soname from
the ones it depends on. My proposal is the same idea, but executed
manually rather than automatically.
The Linux folks tried to tackle this issue without making anybody
change their sonames, at the expense of added complexity in the
dynamic linker system (which, in fairness, already existed because of
compatibility issues between a.out and ELF binaries). I don't think
this is an issue that we should walk into blindly, then code our way
out of.
If we don't use sonames to our advantage right now, we're going to
have to introduce a lot of cruft into the Hurd's shared library
resolution code. I'm hoping we can avoid that mess, keep backward
compatibility with ourselves, and still achieve reasonable
compatibility with the Linux glibc ABI.
Comments are appreciated,
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Reply to: