Date: Mon, 27 Mar 1995 14:51:20 -0700 From: Nate Williams <nate@trout.sri.MT.net> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com>, Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> Cc: Paul Richards <paul@isl.cf.ac.uk>, bde@zeta.org.au (Bruce Evans), davidg@Root.COM, current@FreeBSD.org Subject: Re: shared library versioning Message-ID: <199503272151.OAA03534@trout.sri.MT.net> In-Reply-To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> "Re: shared library versioning" (Mar 27, 1:37pm)
next in thread | previous in thread | raw e-mail | index | archive | help
> > I didn't see a bump, but as a result of this change, it should be. > > So instead of said binaries failing catastrophically on a link > error, they just fail to find the library in question and fail > catastrophically on a missing library? > > I somehow fail to see the point. If we don't bump the shlib #, any binaries that are linked against the new library will think libc.so.2.0 is adequate. Which means IF that binary is moved to a machine that contains a *real* (2.0R) libc.so.2.0 it will fail at runtime because of a missing symbol. The binaries obviously link fine since they are linked against a library that contains all of the necessary symbols. But, libc.so.2.0 to the rest of the world (especially consider the change I made earlier) do not contain the strhash() routines. Programs linked against libc.so.2.0 will run with libc.so.2.1 since the run-time loader will use any minor library >= the original version, but not a minor number less than it was linked against. Clear as mud? Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503272151.OAA03534>