Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]
On Mon, Dec 28, 1998 at 12:28:42PM -0600, Gordon Matzigkeit 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.
Granted.
[...]
> 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.
Ok. So please disregard my proposal :)
[...]
> 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.
Ok, got it.
> 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.
Ok.
> 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.
Yes, in out case it was libc5-compat, and required a lot of changes to the
Debian rules files, and, to be honest, the transition was a pain in the ass
and lasted too long.
> 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.
Ah. I think this is comparable to the debian version numbering scheme. We
use an upstream version and a Debian version, for example 2.01-5, where 2.01
is the upstream version and 5 the Debian version.
In our case, we would have an upstream soname part and a Hurd compatibilty soname
part, right?
> 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.
Ok. This requires only minor manual changes to the debian control files.
However, auto.compilation is not easily possible with those changes
necessary.
> 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
Looks good.
> 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.
I see. This does indeed solve the problem, at the cost ofmore manual work
necessary for us porters. But in return this gives us backward compatibility.
> 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.
Well, the last thing would require that we switch back to Linux sonaming at
some point in the future. If I understood everything correctly, we would
maintain our own sonaming (with two parts, upstream soname and glibc soname)
for hurd library packages, until we have a glibc ABI which is
identical/compatible to the one used by the Linux people, and then we could
drop our additional soname part and stay with the Linux way to do it?
If I did not understood correctly, you must explain how we can get back to
Linux sonaming...
Thank you,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: