[ On Friday, December 17, 1999 at 16:42:03 (-0800), Jason Thorpe wrote: ]
> Subject: Re: src/gnu/usr.bin/egcs/common 
>
> Say you have a program foobar, which you can build from source, which
> links against libzap.so.0 and libc.so.12.
> 
> libzap calls stdio functions.  It is a 3rd party library, and sources
> are not available.
> 
> You bump the libc to libc.so.13, and you rebuild foobar.

I understand this part perfectly.

You won't have any trouble so long as you re-build 'foobar' with
libc.so.12, which would only seem natural to me.  That's why I suggested
the use of '-nostinc -nostlib -I/usr/include.old -I/usr/lib.old', which
assumes that the upgrade process has squirrelled away everything you'd
need to do this.  Perhaps one could also explicitly mention
/usr/lib/libc.so.12 on the command line, though I think having a link to
libc.so.12 in both /usr/lib.old and /usr/lib should suffice (maybe with
a '-Wl,-R/usr/lib' too just to make sure the binary uses the common
directory at run time).

The only tricky part comes when you find some need to rebuild libc.so.12
itself, which means keeping separate source trees locally available.  I
doubt the average usr will face this problem though, and obviously doing
such re-builds implies that you know not to damage the ABI in the process!  :-)

When building complex applications that themselves use various internal
libraries that are separately release managed I always ensure that every
build environment has copies of every release of every library, with the
release name includes as part of the main library name and that the
build tools always explicitly reference the exact release of each
library they intend to use.  Eg. I'd have both libc12.a and libc13.a
in the build environment (adjust to your hearts desire for shared
libraries).  An equally effective scheme is to include the version
number of the library in the parent directory name, and to use the
appropriate '-L' instead of '-l'.  In either case there's probably also
a "generic" set of libraries (and headers) that can be used when a build
doesn't specify an explicit version dependency.

This scheme can apply very well to system system libraries too,
including shared libraries, if one uses the directory naming idea as I
note above.

You don't necessarily want to confuse system releases with library
releases (as there may indeed be no reason to bump the library major
numbers with every system release), though of course some binary-only
vendors will make them synonymous so as to avoid any potential for
confusion or compatibility problems.  In that case they would normally
ship both current and old libraries in every release so that third party
binaries will be usable.

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