[ On Tuesday, October 16, 2001 at 12:54:47 (-0700), Jason R Thorpe wrote: ]
> Subject: Re: stdio FILE extension
>
> ANY library which references ANY function in libc.  That is to say,
> almost ALL libraries provided by ANYONE.
> 
> Consider:
> 
> 	Program linked against libc.so.13 and libfoo.so.1
> 
> 	libfoo.so.1 is an older version that has a dependency
> 	on libc.so.12
> 
> "Boom."

not always "boom" -- only "boom" if an ABI changes....  the run-time
linker should probalbly still load the new libc and try to run the
program anyway....  If it blows up or behaves incorrectly then the
warning it will presumably have printed should be taken seriously, and
otherwise you can cross your fingers and hope for the best.

> In order to avoid this problem, you must bump libfoo.so.1 when any
> library that it depends on is bumped.  In the case of libc, since
> nearly EVERYTHING depends on it, this has far-reaching consequences
> (it doesn't stop at the first level -- now you have to bump anything
> that depends on libfoo.so ... and so on).

Yes of course -- I think everyone understands this by now.

But so what?  Who cares?  (I mean that literally, not sarcastically --
those who do should speak up and give very explicit examples of the
problems they percieve with dynamic libc major number bumps!)

Such a bump should be mandatory with every ``major'' full-system release
(and in NetBSD's case I'd even venture to say that's any increment from
1.x to 1.x+1).  It happens regardless for anything statically linked, so
why not for dynamically linked stuff too?

That way things would never get so badly out-of-whack as they are
perceived to be now -- the libc bump becomes a normal part of every
_major_ upgrade and people who don't want to bump their libc for
whatever reason do not _really_ want to upgrade so badly otherwise
they'd take the plunge.  You can't still have your cake and have eaten
it too!  (Well, with binary emulation we could provide support for old
binaries on new systems in the same way as we do now for foreign system
binaries, and a.out binaries on elf systems, etc. -- an upgrade would
thus require effectively moving /usr to /emul/netbsd-1.[X-1]/usr.)

There's certainly no harm in NetBSD "forcing" third-party library
vendors to re-compile and issue new releases of their libraries every
time the base OS undergoes a major release.  This would be a _good_
thing!  People who want to ride the wave of ongoing improvements should
do so with full knowledge of what they're getting into.

The only *real* alternative here is to outlaw interlibrary dependencies
(something we should consider serisouly if we're to learn from the
mistakes of M$ DLLs and such!), which I guess means statically linking
libc stuff into any shared library that needs it and so on, and that of
course forces the issue in much the same way a major-number bump does --
third party libraries must be upgraded at the same time the critical OS
components they depend upon are upgraded, and such a requirement is a
_good_ thing, even when it causes some minor conflict in a few people's
lives.  If you want the new base OS then you must be prepared to do
whatever it takes to get the applications you use to be fully supported
on that new OS -- otherwise you can stay running them on the old OS
where they are presumably still fully supported.

A dynamically linked libc cannot shield third-party applications from
kernel ABI changes forever, at least not without it becoming an
anachronism itself.

Just because we have shared libraries doesn't mean we can avoid the very
real issues of version skew, multi-level dependencies, and such.  If
used carefully shared libraries can bring some important benefits, but
these benefits should not be confused with the onging very real need to
deal with API and ABI changes in an evolving systems platform.

Silly hacks which allow an API to get out-of-sync with the ABI should
not be relied upon to maintain an ABI across a major system release.
Anyone who thinks otherwise is living an illusion and the fact that
NetBSD got this far using such hacks is only a testament to the
dedication and careful planning of the developers past and present.
However if those developers should not expect the same level of respect
if they try ot foist their clever but increasingly complex and limiting
hacks on all future users.  Every major NetBSD release should start
fresh with no renames in libc and no differences between the static and
dynamic libc ABI.

-- 
							Greg A. Woods

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