Perhaps my understanding is wrong, I always (naively) thought:
* that feature was for license compatibility mostly.
* Qt would still try to dlopen libcrypto.so.10 at runtime, leading to problems anyway

That said, we can consider this anyway

(In reply to Rex Dieter from comment #1)
> Perhaps my understanding is wrong, I always (naively) thought:
> * that feature was for license compatibility mostly.
> * Qt would still try to dlopen libcrypto.so.10 at runtime, leading to
> problems anyway
> 
> That said, we can consider this anyway

by default, the SSL-enabled Qt library dynamically loads any installed OpenSSL
library at run-time. With the options "-openssl-linked" the qt library links the library (openssl) at compile-time, that means Qt lib stops to load openssl libs dynamically and the users cannot use own ssl libs in this case.

I don't see any benenit and it is a limitation for the users. In my opinion we should drop this flag in rawhide.

I will drop it in rawhide if KDESIGmembers don't have objection.

Thank, go ahead.

No objections on that.

thanks, it's fixed in the rawhide

Make sure to test this thoroughly... while we're at it... maybe consider now adding a dep on openssl-libs,

Requires: openssl-libs%{?_isa}

since related crypto operations will now fail if it's not present to be dynamically loaded.  (or maybe consider soft dep, but not sure if it's worth the risk)

Also, should we consider doing the same change in qt(4) too?

By flag you mean --openssl-linked flag?

Yes

That sounds troublesome. We could run into binary incompatibility issues. 

We build qt5, app (based on qt5) all using local openssl version X.

What if we build qt5 using openssl version X header file and then app uses different openssl version headers? Wont there be binary incompatiblity if some API changed between versions?

I think you may misunderstand, qt packages currently use --openssl-linked, I'm suggesting to *drop* that in qt(4) like what we have done here with qt5-qtbase

That should be safe for the concern you mention.

Rex, you are right I misunderstood. This is welcome change and should be ported back to qt4. Lots of distros still use older version

I don't agree with this change at all. By that argument, we should dlopen everything, that does not make sense.

NULLED, if you really want to mess with OpenSSL, why don't you use LD_LIBRARY_PATH or ld.so.conf.d, which will both work just fine no matter whether dlopen or direct linking is used?

Using dlopen hurts performance and makes it harder to detect incompatibilities. (We even have to hardcode the Requires in RPM that would be autodetected otherwise. And the Requires is hard to correctly version. Right now, it is unversioned, so incompatible sonames are no longer detected.)

We really need to change this back!

> why don't you use LD_LIBRARY_PATH or ld.so.conf.d

or even an embedded DT_RUNPATH or DT_RPATH in your executables

Oh, and if your concern is choosing between OpenSSL 1.0 or 1.1, using dlopen will not help that, because whether to use 1.0 or 1.1 is decided at build time even if dlopen is used.

I can see only disadvantages from switching to dlopen.

> by default, the SSL-enabled Qt library dynamically loads any installed OpenSSL
> library at run-time. With the options "-openssl-linked" the qt library links 
> the library (openssl) at compile-time, that means Qt lib stops to load openssl 
> libs dynamically and the users cannot use own ssl libs in this case.

This is not true. At least LD_LIBRARY_PATH and ld.so.conf.d can be used to override the library search path. LD_LIBRARY_PATH can be set by a wrapper script for an individual application. This is often done. ld.so.conf.d is for system-wide overrides, see e.g. freetype-freeworld.

> I don't see any benenit and it is a limitation for the users.

The benefits of using -openssl-linked are that:
* RPM automatically detects the soname dependency,
* RPM even automatically detects ELF symbol versioning dependencies, which the OpenSSL 1.1 packaging now uses,
* mismatches between the expected and actual OpenSSL API are detected at compile time (rather than causing a crash at runtime because dlopen is not type-safe at all, it happily casts to the expected function prototype that may be completely different from the actual one).
Basically, it allows us to properly ensure that the package is rebuilt when OpenSSL changes incompatibly.

On the other hand, I see no benefit whatsoever to NOT using -openssl-linked in a distro package. The dlopen option is intended for the Qt Project's own binary packages, which have to work on many different distros.

Case in point, the current Rawhide qt5-qtbase can be installed on F25 (due to the unversioned openssl dependency), where it will crash and burn. Switching back to -openssl-linked will fix that.

FYI, restored -openssl-linked for qt4 at least temporarily while working on rawhide FTBFS issue bug #1400196

Sorry, but it was decided that -openssl-linked is really the sanest approach for a distribution package.