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:33:58 +0000 (18:33 -0500)
commit822b5e2645a99bea15329bd66c9723c7e7119cdb
tree96c1adc3e422f84458e71bebb51887179f87dce6
parenta4cefc86c820d3894ca960857ba4e7cf8e2014b0
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