On Wed, 20 Dec 2000, Jun-ichiro itojun Hagino wrote:

: 	i noticed the following comment in lib/libc/shlib_version:
: ># - libc/gen/assert.c: __{diag,}assert13() -> __{diag,}assert()
:
: 	actually, i believe we can nuke all __RENAME(), covered by libc,
: 	when we increase shlib major (and then we will populate new __RENAME()
: 	whenever we make incompatible change without shlib major upgrade).
: 	am I correct?

Actually, libc may never have its major version bumped.

The problem is somewhat obvious, if you look at the layout of system
libraries.  libc.so.12 is required by all libraries currently compiled on
the system.  If you bump to libc.so.13, and compile a program using a third
party shared library "libfoo" compiled against the old libc:

cc -o program -lfoo

The libfoo library needs code in libc.so.12; however, the program will
implicity link against libc.so.13.  There is a library conflict now.

In order to bump libc's major number, _all_ other shared libraries must be
recompiled.  This probably won't happen -- and is the same reason that
Solaris's libc major has never been bumped.  (We tried bumping libc's major
number once, and the dependencies failed miserably.)

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi NetBSD:  Run with it.
-- NetBSD 1.5 now available on CD-ROM  --  http://www.wasabisystems.com/