[Interest] Linux openssl 1.1.0 versus 1.0.X

[Roland Winklmeier]

Christophe Thomas <oxygen77.ct at gmail.com> schrieb am So., 16. Sep. 2018,
10:41:

> Hello,
>
> From the comment of Giuseppe I understand that we could go with just a
> package installation. I've an ubuntu 18.04 (not installed from scratch but
> from an upgrade of 16.04). When I look in /usr/lib/x86_64-linux-gnu/, I
> have several libssl
> => libssl.so (symlink to libssl.so.1.1)
> => libssl.so.1.1
> => libssl.so.1.0
> I can also see a folder: /usr/lib/x86_64-linux-gnu/openssl-1.0.0
>
> This is consistent with the fact that I have following packages:
> libssl-dev/bionic-security,bionic-updates,now 1.1.0g-2ubuntu4.1 amd64
> libssl1.0.0/bionic-security,bionic-updates,now 1.0.2n-1ubuntu5.1 amd64
> libssl1.1/bionic-security,bionic-updates,now 1.1.0g-2ubuntu4.1 amd64
>
> Event then I still get the SSL error in Qt:
> Several : qt.network.ssl: QSslSocket: cannot resolve and finaly
> then : qt.network.ssl: Incompatible version of OpenSSL
> and several : qt.network.ssl: QSslSocket: cannot call unresolved function
>
> I've tryed to modify the symlink to have libssl.so => libssl.so.1.0 but it
> didn't do the trick.
>
> How do you think I can make my Qt app find the right SSL lib ?
>
> Chris
>

Hi Chris,

I ran into the same problem the other day. Qt is loading openssl
dynamically at runtime. This is failing on many newer platforms now since
they usually have symlinks pointing to openssl 1.1 as it is on your case. I
do not recommend to change the system symlinks since that has impact an all
your distribution binaries with huge negative impact.
The only workaround I could find without modifying the system path was to
add symlinks in my applications path (or any other) and add that directory
to the LD_LIBRARY_PATH environmental variable. This way Qt found and loaded
openssl 1.0 without issues. The workaround is still annoying since one had
to add wrapper scripts.

Ideally Qt would load any version at runtime. So far it's a compile time
decision only. Would it be possible to built support for both? If that's
not possible, it should try to load the versioned binaries (e.g
libssl.so.1.0) first and only if not available fall back to the unversioned
library name. This should avoid conflicts like this.

Cheers Roland

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180916/b2a329b8/attachment.html>