On Fri, 26 Jun 2020, Wayne Sherman wrote:
On Thu, Jun 25, 2020 at 11:43 PM Michael Van Canneyt
<mich...@freepascal.org> wrote:
3) I recommend the newest libraries be tried first, working backwards
towards the oldest.
This is already so ? The version numbers are added from new to old ?
The libraries are currently loading in this order:
First attempt: ssleay32.dll / libeay32.dll (older names, but not oldest)
Second attempt (util): libcrypto-1_1-x64.dll (newest name)
Third attempt (ssl): libssl32.dll (oldest name)
Fourth attempt (ssl): libssl-1_1-x64.dll (newest name)
Oh, you mean the DLL names.
I thought you meant the version numbers. Yes, this can be changed too.
This needs to be checked.
I ran a test. If a system has a stray file it can cause mismatched
DLLs to load (which could result in strange bugs)
Please see attached image "OpenSSL_dll_loading_screenshot.png"
We'll adapt the mechanism.
I have changed that to 4.0
From: https://www.openssl.org/policies/releasestrat.html
openssl versions 1.1.0, 1.0.2, 1.0.1, 1.0.0 and 0.9.8 are no
longer supported
Maybe, but for backwards compatibility they must be supported in FPC.
So can Windows openssl v1.1 library loading be included in the next
maintenance release (v3.2.1?) instead of waiting for v4.0?
No worries, 4.0 means we can consider it for the next fix release.
That will be 3.2.2 (even numbers only for releases, odd indicates
development sources)
Would you like me to have a go at a revised patch?
Sure. If you create a patch, upload it to the bugtracker and assign it to me
(or mail here so I can have a look)
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
