[ On Saturday, December 6, 2003 at 20:02:38 (-0600), Eric Haszlakiewicz wrote: ]
> Subject: Re: NetBSD 2.0 release date
>
> 	I believe the problem is that (almost) all libraries have an _implicit_
> dependency on libc.  This means that the particular version of libc that
> actually gets loaded at run time is controlled by what the final binary
> is linked against.  Say you have binary foo, linked against libbar.1.
> Both of those were linked against libc.12.  Now go rebuild libbar using
> libc.13.  Since the libbar major version hasn't been bumped the binary
> foo will continue to use it, but the wrong version of libc will be used
> causing the code in libbar that was compiled against libc.13 to likely
> break in various ways.

You are concocting a situation that will not occur, by design.

As has been discussed numerous times in the past it is expected that all
shared libraries supplied with the system will have their major version
numbers incremented and that the old versions will remain available for
old binaries.  All vedors of proprietary shared libraries will also be
made well aware of the fact that they must also provide their users with
new shared libraries with incremented version numbers.

IIRC, and IIUC, the relevant mistake that has been made in the past, and
which may still be being made, is that shared libraries do not record
the version identifiers of other shared libraries they must be linked
against.

This does make it difficult to identify potential conflicts in the most
obvious and direct manner.

However since most NetBSD users will either use pre-built packages from
one consistent source (in which case they will have no worries) or they
will rebuild programs from source (in which case these issues need only
be considered during the recompilation and relinking of a new shared
binary).

In the latter case the issues are no different than they are for static
libraries.  Linking a program with an "old" library is not guaranteed to
work.  There is no simpler or more obvious rule and even the most naive
user will understand it and accept it.

>  The fact that the old libraries are still installed
> actually works against you here: programs will run even though it is
> dangerous for them to do so.

Actually no, it won't.  There will only be a problem if the kernel ABI
has changed in a non-backwards compatible way, and provided the COMPAT_*
options are maintained, there will be no problem for old binaries.

> 	If there was an explicit dependency in the library then this could 
> be caught by ld.so and it could refuse to run the program.

Timestamps are quite sufficient.  All libraries must be re-compiled
before new programs are linked with them.  A system upgrade procedure
need only check that no libraries (static or shared) have timestamps in
the future.  The linker need only check that no library has a timestamps
prior to the system upgrade.

-- 
						Greg A. Woods

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