Subject: Re: NetBSD 2.0 release date
To: Eric Haszlakiewicz <erh@jodi.nimenees.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 12/08/2003 16:37:50
--ZInfyf7laFu/Kiw7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 08, 2003 at 12:28:27PM -0600, Eric Haszlakiewicz wrote:
> On Mon, Dec 08, 2003 at 01:02:20PM -0500, John Franklin wrote:
> > On Dec 8, 2003, at 12:03 PM, Jason Thorpe wrote:
> > >What if program foo was compiled on a different host, and you received=
=20
> > >it as a binary?  What if, on that other hose, libother.0 had a=20
> > >recorded dependency on libc.13 (i.e. it is a "fresh install"), but you=
=20
> > >are running it on a host that has an older libother.0 that has the=20
> > >libc.12 dependency.
> 	or you just went and updated libother.0 without updating the program.
> (e.g. in pkgsrc parlance: make replace)

My recolection is that "make replace" is documented as a, "use at your own=
=20
risk" kinda thing. :-)

> > On the other host, foo is linked with libc.13 and libother.0=20
> > dependencies.  Locally, the loader would try to load both libc.13 (to=
=20
> > satisfy the foo dependency) and libc.12 (to satisfy the libother.0=20
> > dependency.)  Conflicting library versions, program doesn't load, error=
=20
> > is returned.  It's OK for the loader to say no.
> 	what would be really neat is if the ld.so would look for earlier versions
> of libother.0 that has the matching dependency.  If libother.0.2 is linked
> against libc.13, but libother.0.1 exists and is linked against libc.12, t=
hen
> program foo, linked against libother.0 and libc.12 should be able to work
> just fine using libother.0.1.  _That_ would allow full backwards compatib=
ility
> without bumping major versions.

I think we want to bump all the versions. I think to do anything else=20
would be a mistake. As Jason notes, there is a scheme for naming shared=20
libraries, and the names have meaning relative to each other. What we're=20
talking about is the kind of change that is expressed by changing the=20
major number.

One of the features of minor numbers is that if you were compiled using=20
version x.y of a shared library, you can use version x.(y+n) for any n=20
>=3D 0. A libc version flip like you describe doesn't fit that rule. :-)

Also, I don't think the runtime linker should be making decisions like=20
this. I think which version of libc a program and/or library will work=20
with should be decided at compile time, so at run time we just need to=20
find the appropriate library.

Take care,

Bill

--ZInfyf7laFu/Kiw7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/1RldWz+3JHUci9cRAjb8AJ9vEbUE38iw14wV0HBNEoHc4fq5TACeI199
H0UcTNusjQRTWxLGJfBCBsQ=
=TuFv
-----END PGP SIGNATURE-----

--ZInfyf7laFu/Kiw7--