Make possible variant SONAMEs and symbol versions
authorViktor Dukhovni <openssl-users@dukhovni.org>
Tue, 21 Nov 2017 02:30:04 +0000 (21:30 -0500)
committerViktor Dukhovni <openssl-users@dukhovni.org>
Thu, 30 Nov 2017 23:27:50 +0000 (18:27 -0500)
commite6f38fb817d831ed093f7d7140325783b5556d8f
tree5a705df0f336c020dbd1a7800bb74c3b47c0bc75
parenta61c15eb9b8d0ef513d695c854516958e2ccf1eb
Make possible variant SONAMEs and symbol versions

This small change in the Unix template and shared library build
scripts enables building "variant" shared libraries.  A "variant"
shared library has a non-default SONAME, and non default symbol
versions.  This makes it possible to build (say) an OpenSSL 1.1.0
library that can coexist without conflict in the same process address
space as the system's default OpenSSL library which may be OpenSSL
1.0.2.

Such "variant" shared libraries make it possible to link applications
against a custom OpenSSL library installed in /opt/openssl/1.1 or
similar location, and not risk conflict with an indirectly loaded
OpenSSL runtime that is required by some other dependency.

Variant shared libraries have been fully tested under Linux, and
build successfully on MacOS/X producing variant DYLD names.  MacOS/X
Darwin has no symbol versioning, but has a non-flat library namespace.
Variant libraries may therefore support multiple OpenSSL libraries
in the same address space also with MacOS/X, despite lack of symbol
versions, but this has not been verified.

Variant shared libraries are optional and off by default.

Reviewed-by: Richard Levitte <levitte@openssl.org>
Configurations/README
Configurations/unix-Makefile.tmpl
util/mkdef.pl