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 [EMAIL PROTECTED] for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
