[Interest] Linux openssl 1.1.0 versus 1.0.X

[Allan Sandfeld Jensen]

On Sonntag, 16. September 2018 12:14:28 CEST Roland Winklmeier wrote:
> 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.
> 
No, it is not possible to support both without a lot of work, and since the 
problem will go away soon, it is not worth it. Loading libssl.so.1.0 before 
trying libssl.so might work though, at least if any distros exist with both 
libraries.

Alternatively link to libssl instead of loading it as runtime, I believe that 
is still a configure option.

'Allan