Subject: Re: src/gnu/usr.bin/egcs/common
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 12/17/1999 21:02:58
[ On , December 17, 1999 at 16:42:39 (-0800), Chris G. Demetriou wrote: ]
> Subject: Re: src/gnu/usr.bin/egcs/common
> > Secondly, won't this mostly only affect people doing binary upgrades
> > (which of course includes those building and tracking -current, albeit
> > in a slightly different way), and won't the retention of old library
> > binaries solve this? I can't see this part being any more difficult
> > than doing an a.out->elf transition.
> What's a binary upgrade? using the binary you happened to compile
> three releases ago? Using the pre-compiled binary application?
Yes. A binary upgrade is where you've got a system running release (X)
with third-party binaries depending on the shared libraries in (X).
When you install release (X+1) you keep all the shared libraries for (X)
installed too and all should be OK.
From what I can see problems don't occur until you start compiling
things again, and then only if you've got old third-party libraries
mixed into the fray.
> libc.X (ok, got it, we've got the compat pkg installed)
> libfoo.Y (we've got it; it's a current libarary)
> libc.(X+1) (because of the libfoo.Y dependency)
> note that that needs two, incompatible, versions of libc, which
> doesn't and can't function properly.
OK, that I knew that. But you do explain very well why all library
major numbers have to be bumped at once! :-)
(indeed this is essentially the same issue as someone was discussing
about glibc version conflicts I think)
> As an aside: Note that for many base system libraries we currently
> (incorrectly) do _NOT_ specify the dependency on libc or other
> libraries whose interfaces are used. This is a historical artifact of
> the build process, and is incorrect. Some of the base system
> libraries, on the other hand, do at least part of the right thing, and
> most if not all of the X11 libraries do.)
Ah ha! This is interesting.
Won't bumping library major numbers make it possible to clean up all
this mess in one swoop? How much extra work does this cleanup require?
Greg A. Woods
+1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>