On Mon, Jul 23, 2001 at 03:36:22PM +0200, Hans Werner Strube wrote:
> OpenSSL version: 0.9.6b 9 Jul 2001
> platform: solaris-sparcv8-cc
> This concerns not an actual bug in compilation or function but an annoying
> deviation from the standards of shared library versioning. All the bugfix
> subversions of 0.9.6{,a,b} have the same extension lib...so.0.9.6 but are
> not replaceable because of the builtin check for OPENSSL_VERSION_NUMBER.
> Normally, equal extensions indicate compatibility (at least with respect to
> library updates), i.e., the newer version contains all the globals and
> functions of the older one with the same semantics and argument types. This
> is probably the case between 0.9.6a and 0.9.6b; at least the names of the
> globals and functions are identical. Then programs built with (e.g.) 0.9.6a
> should not have to be recompiled when the shared library is replaced with
> 0.9.6b (but with the same extension); but actually, the new library refuses
> to work with the programs due to the internal check. If, however, the
> libraries are indeed not compatible in the above sense, they should have
> different version extensions.
Your complaint is half-correct.
It is incorrect in the sense that shared library support before 0.9.7 (not
yet released) is called experimental. So we don't give any guarantee on
behaviour or compatibility.
It is correct in the sense that using the same name (0.9.6) for different
versions, that are not binary compatible, does not make sense.
We'll have to keep this in mind for the 0.9.7 and later versions.
> Unfortunately most public-domain software does not treat shared library
> versioning correctly. It should be a general philosophy to keep compatibility
> (and thus, same extension numbers) as long as possible. Internal checks
> (or alternatively, Solaris's "internal versioning") should only reject
> attempts of incompatible downgrading to an older library with the same
> version extension but fewer globals and functions.
I agree with this general philosophy. The development of OpenSSL however
will require further changes of data structures so please don't expect
binary compatibility coming soon.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
