Subject: Re: src/gnu/usr.bin/egcs/common
To: None <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-userlevel
Date: 12/17/1999 19:27:56
[ On , December 17, 1999 at 14:38:51 (-0800), Chris G. Demetriou wrote: ]
> Subject: Re: src/gnu/usr.bin/egcs/common
>
> What we _would_ need to do is bump the major number of every shared
> library that depends on libc, or else incompatibilities would result.
> That's not just fun, it's pretty much intractable.

I confess I don't really understand.  And I share MCR's frustration
(though at the moment I don't myself have any direct need to ``fix'' all
the problems that could be fixed by bumping the major numbers).

First off, doe anything prevent any given system from having copies of
the old libraries during a transition phase?

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.

Obviously it'll take time (two full release cycles?) before the old
syscalls can be cleaned out (i.e. the kernel still has to support the
old binary libraries) and there is the risk that they will be broken
accidentally during this time unless enough people can test them on an
ongoing basis.  I don't think this would be a show stopper though.

The only real problem I see is that some users will also have to retain
old and .h files, and perhaps .a files too, if they have to compile
anything with any third-party binary-only library that requires an older
system library.  I would think though that this can be solved by moving
them to "lib.old" and "include.old" or something similar and using
"-nostdinc -nostdlib -I/usr/include.old -L/usr/lib.old", etc.  Having
tools available to assist in the final cleanup after transition would
obviously help too otherwise people may never eradicate the old gunge
completely....

If this versioning of shared libraries isn't really possible (never mind
easy), doesn't that indicate a really fundamental problem with the whole
concept?  Does *anyone* have a more tractable but generic solution?  If
not is there anyone doing any research on this topic?  (I know someone
who has done some research into shared libraries on a wide variety of
systems, but so far as I know he hasn't yet had the desire to write it
up and publish it, nor do I know if he knows of any solution better than
simply banning all dynamic linking!  ;-)

Lastly, what's so difficult with having different library version
numbers on each architecture?  Isn't it simply a matter of adding the
appropriate if/elif statement to the right .mk files?

Has anyone actually experimented with doing such a bump?  If so, how far
did you go -- right through to making and testing install media and
doing both a bare-system install as well as an upgrade?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>