Subject: RE: src/gnu/usr.bin/egcs/common
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-userlevel
Date: 12/19/1999 13:35:33
[ On Sunday, December 19, 1999 at 10:03:59 (+0100), Martin Husemann wrote: ]
> Subject: RE: src/gnu/usr.bin/egcs/common
>
> > library major numbers really do have to be bumped.  The hardest thing to
> > do after getting all the old files squirrelled safely away where they
> > can be used might be fooling GNU Autoconf generated "configure" scripts
> > into only using the old library and headers.
> 
> The includes could be #ifdef __MULTITHREADING or something similar and the

Note that there's no one specific "feature" to test for here -- this
procedure and framework should be usable for any upgrade in the library
major numbers.  A threaded libc is just one excuse for bumping the
shared library major numbers.

After I posted that message I remembered that Autoconf scripts should
always honour $CC, $CFLAGS, and so on, so it should be possible to
convince them to only look in /usr/*.old, and even if they don't then
you can fix them with patches in the pkgsrc module created for such
third-party libraries.

Another problem I thought about afterwards is the issue of
/usr/local/lib (i.e. stuff installed on a system by hand).

Not a whole lot can be done about ensuring that local stuff which might
include binary-only shared libraries dependent on the old libc.so will
still be usable for development after an OS upgrade.  I suppose the
upgrade script could wander about the filesystem looking for non-system
shared libraries and simply utter warnings about them.  The user could
be directed to look at the upgrade script for a template of how to deal
with saving such libraries so that they can be used while at the same
time allowing the rest of the /usr/local stuff to be re-compiled and
re-installed to use the new system libraries.

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