Subject: Re: ATTENTION: avoid using libc.13
To: Frank van der Linden <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 10/21/1997 13:03:14
[ On Tue, October 21, 1997 at 17:07:18 (+0200), Frank van der Linden wrote: ]
> Subject: Re: ATTENTION: avoid using libc.13
> So, you ship 1.3 with libc.so.14. A first time user does a clean install
> of 1.3, and then gets Xfree86. "ld.so: libc.so.12 not found". Oops.
> "nothing gets broken?" I think not.
Then something in shared library land *is* far more broken than I'd
assumed. I am fully aware of the issues of libraries depending on other
libraries (and/or even on each other). That's exactly why Sun chose to
version number the function calls and *not* *ever* break backward
compatability with old interfaces. This is one of the limitations of
using shared libraries in the first place -- if you want the freedom to
break backwards compatability of library interfaces then you *cannot*
have your cake and eat it too with shared libraries.
The only other solutions involve eliminating inter-library dependencies,
or merging all libraries into one large monster (ala AIX), or always
bump all the major numbers of *all* libraries at the same time, or other
not so helpful things.
The way Sun seem to have got around the error was to never change the
major number (which they used on SunOS-4 to designate the difference
between the UCB and Sys5 libraries) and of course never break old
interfaces but instead they use a three level suffix, i.e. a minor for
the OS and a sub-minor for the user. Although the sub-minor isn't
documented it does seem to work (i.e. ldconfig sees it and ld.so
properly loads the newest sub-minor version).
However I do agree that if you are going to break old interfaces then
the only thing you can do is change the major number and always ship all
the old libraries that you want to support. I suppose this could be
done in the build environment, at least for the libraries shipped with
the OS. If this can't be done for NetBSD-1.3 then I also agree the
only solution is to back down to .12 library and undo the interface
In the larger picture something better than this needs to be done for
the (near) future.
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <firstname.lastname@example.org>; Secrets Of The Weird <email@example.com>