20.11.2016 в 20:01:25 +0100 Jan Niehusmann написал: > On Sun, Nov 20, 2016 at 07:40:22PM +0400, Stepan Golosunov wrote: > > If SONAME change is needed it is needed when linking libcurl with > > libssl1.0.2 too. (But when linking libcurl with libssl1.0.2 more > > applications are affected due to the need of explicit initialization.) > > Upstream documentation suggests that this is not true: > > "Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, can > and are likely to contain new features, but in a way that does not break > binary compatibility. This means that an application compiled and > dynamically linked with 1.0.0 does not need to be recompiled when the > shared library is updated to 1.0.2." > (https://www.openssl.org/policies/releasestrat.html) > > But of course, in practice, there may have been unintended ABI changes > - so yes, may be a SONAME change is nessary for 1.0.2 as well. I just > don't know.
SONAME for OpenSSL 1.0.2 in Debian was changed because it was recompiled with different options to remove some deprecated (but widely used) functions. And if application initializes libssl1.0.0 then libssl1.0.2 is left uninitialized and does not work correctly, while libssl1.1 does not need explicit initialization at all. OpenSSL libraries have lots of global state, so passing pointers created with libssl1.0.2 to libssl1.0.0 isn't safe. Different features and implementation details of the two libraries are likely to cause problems too in that case. > Still, for 1.1 the SONAME change is definitely necessary. Breaks: against applications using CURLOPT_SSL_CTX_FUNCTION and compiled with OpenSSL 1.0 will probably suffice in that case.
