Thiago Macieira <thiago.macie...@intel.com> schrieb am Mo. 17. Sep. 2018 um 00:27:
> On Sunday, 16 September 2018 03:18:39 PDT Allan Sandfeld Jensen wrote: > > 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. > > QtNetwork already does that. It loads the libssl with the full soname that > it > was configured with. That is provided by the macro SHLIB_VERSION_NUMBER > found > in the openssl/opensslv.h header. > Oh I didn’t know that. I just checked on my Debian Stretch and it has a libssl.so.1.0.2 but no symlink libssl.so.1.0. Going through the OpenSSL load attempts in QtNetwork then I think it tries in the the following order: 1. libssl.so.1.0 - not found since not added by the distributor. 2. libssl.so which on Debian links to libssl.so.1.1 -> Found and load OpenSSL 1.1. So if I simply add a symlink for libssl.so.1.0 -> libssl.so.1.0.2 and the same for crypto then it should find OpenSSL 1.0 instead? I also need to check for openSUSE 15, since I had the same problem there. Cheers Roland
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
