From: "Maciej W. Rozycki" <[EMAIL PROTECTED]>
macro> Following is a fix for shared library versioning. Currently
macro> the full version number is used as a part of shared libraries
macro> SONAMEs. As a result subsequent library revisions are marked
macro> as incompatible and all the programs linked against these
macro> libraries must get rebuilt. This way e.g version 0.9.5a is
macro> incompatible to version 0.9.6b. This completely defeats the
macro> shared libraries versioning system -- you may equally well not
macro> include a version number in SONAMEs. There is no point in
macro> making lib*.so.0 symlinks in this case as well -- they are
macro> never used.
Actually, this is intentional, and we're warning people about this
regularly. To summarise: the OpenSSL team does not currently
guarantee backward binary compatibility, and we have said numerous
times that we will only start keeping compatibility at version 1.0.
Furthermore, the shared library support is currently only
*experimental*, for the same reason.
So, you're correct, shared libraries are pointless except in the
following two points:
1. if several programs are linked against libcrypto.so.0.9.6b, for
example, you save memory compared to have several programs link
to it statically.
2. the development of the shared library building methods is going
slowly, so you can see the current experimental status as a
preparation for the time where we (hopefully) *will* support
shared libraries, i.e. starting at version 1.0
Note however that we are often (and have been so far) compatible on
the patch level, so for example OpenSSL 0.9.6, 0.9.6a and 0.9.6b all
get the soname libcrypto.so.0.9.6 and libssl.so.0.9.6 and as far as I
know, that works.
When we officially support shared libraries, we most probably will
call the sonames things like libcrypto.so.1...
For those who play with VMS, I've added a command procedure in the
current development branch (i.e. the snapshots that lead to 0.9.7)
called [.VMS]MKSHARED.COM (VMS/mkshared.com for the Unixly impaired
:-)). It follows the same rules as said above, so currently, the
library version number becomes 0,970, and when (if) 0.9.7a comes out,
it will be 0,971. It's very possible that it'll follow a completely
different schema when we start with version 1.0.
Thanks for your contribution still.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
