[Buildroot] No OpenSSL 1.1.x support in Qt 5.6.x.

[James Grant]

On 1/03/2019 22:07, Peter Korsgaard wrote:
>>>>>> "James" == James Grant<james.grant at jci.com>  writes:
>   > Hi,
>   > There is no OpenSSL 1.1.x support in Qt 5.6.x and no-one appears to have back-ported support.
>
>   >https://development.qt-project.narkive.com/RW4wxYXY/openssl-1-1-x-support-on-qt-5-6-5-9
>
>   > I'm suggesting that for upcoming 2019.02 release that no attempt is made to build with SSL support for 5.6.
>
>   > About to send patch to that effect.
>
> Yes. I was hoping that users of Qt 5.6 would step up and send patches,
> but given that hasn't happened and 2019.02 is overdue, that is probably
> the least bad solution.
>
> Looking forward to your patch.

Earliest version of a OpenSSL 1.1 patch for Qt 5.x I can find is against 
Qt 5.7 (LGPLv3). If you adapted / backported that for Qt 5.6 there is an 
argument you're contaminating LGPLv2 Qt5.6 with LGPLv3 code - defeating 
the whole point of keeping Qt 5.6 for many.

I got Qt 5.6 compiling with LibreSSL (which is keeping a level of 
OpenSSL 1.0 compatibility).  Currently Qt is set to dlopen() OpenSSL at 
runtime (-openssl), changing this to shared linkage (-openssl-linked), 
then compiling only the SSL module with -fpermissive yields a working 
build. No actual code changes needed.

Is there really any benefit to dlopen() OpenSSL on an embedded system in 
any case?

The -fpermissive flag is needed to workaround  'const BIO_METHOD *' vs. 
'BIO_METHOD *' changes to BIO_new() and BIO_s_mem() function signatures.

'download' example successfully downloaded a file from a https site for me.

Should I put together a patch doing this? ... or is someone likely to 
come forward with a more comprehensive LGPLv2 licensed fix?

Regards,
James Grant.