[Interest] Linux openssl 1.1.0 versus 1.0.X

[maitai]

Hello,

I don't think the problem will be gone any time soon. I know plenty of 
users who never update anything...

I noticed that qtCreator ships ssl and crypto libs (into 
Tools/QtCreator/lib/Qt/lib). I just put these 6 files into my own libs 
directory and hop, all good, no recompilation needed.

I know it is bad. But well, if it is good enough for QtCreator, it's 
good for me too.

Philippe.

Le 16-09-2018 12:18, Allan Sandfeld Jensen a écrit :
> 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
> 
> 
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest