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 <[EMAIL PROTECTED]> //\ 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.]