Am Mo., 17. Sep. 2018 um 05:36 Uhr schrieb Thiago Macieira < thiago.macie...@intel.com>:
> Also, please note that this only applies to something compiled *on* > Debian. > The official Qt binaries from download.qt.io are not compiled on Debian. > ... > But again, the official Qt binaries are not compiled on openSUSE. > And that's exactly the problem that the thread originator and myself are trying to workaround. Speaking for myself only, I don't have the time and resources to build my hobby project on all important Linux distributions natively. Instead I build it on a single distribution that has gcc >= 5 and the oldest glibc I could find (currently Ubuntu 16.04 LTS) using the official Qt binaries. Those are built against OpenSSL 1.0, but newer distributions ship with OpenSSL 1.1 per default and provide 1.0 as a parallel installation. Thats where the conflict starts and we were trying to find workarounds to use the offical Qt binaries also on those newer distributions. I don't think Debian nor Qt are wrong in what they are doing, I just try to get it working anyway. If I got you right, then I would have to find out what SONAME the official Qt binaries are expecting. I don't have RHEL available so maybe someone else could tell me. Everything _should_ work by adding a symlink named to what RHEL OpenSSL SONAME is configured, pointing to the distributions OpenSSL 1.0 libraries and placed in the standard linker lookup path. That would be a lot easier than what I have now (using symlinks to OpenSSL 1.0 in a local folder and then using LD_LIBRARY_PATH to tell the linker to find my symlinks before the system ones).
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
