Skip site navigation (1)Skip section navigation (2)
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>