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

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.


>  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.

> 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

> 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,

"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: