OpenSSL DLLs required for `libcurl.dll`

[jay]

Reported by John Emmas on curl-library mailing list:

I revisited that web page and noticed it says that curl 7.75.0 is linked
statically to OpenSSL 1.1.1i, so I downloaded the 64-bit zip file -
BUT... when I run the Windows 'dumpbin' program it gives me this output:-

     Dump of file libcurl-x64.dll
     File Type: DLL

       Image has the following dependencies:
         libcrypto-1_1-x64.dll
         libssl-1_1-x64.dll
         ADVAPI32.dll
         CRYPT32.dll
         KERNEL32.dll
         msvcrt.dll
         Normaliz.dll
         USER32.dll
         WLDAP32.dll
         WS2_32.dll

In other words, 'libcrypto-1_1-x64.dll' and 'libssl-1_1-x64.dll' are
both still needed - i.e. they're linked dynamically - not statically :-(

The zip file contains a file called 'libcurl'a' (which looks like it
might be a static lib) but if I try to link against it I get lots of
missing symbols.

Possibly related to #12. I will follow up with a reply explaining that the other libraries can be downloaded in the Specifications section of the download page, and OpenSSL is statically linked in the curl tool, not the library. Why is that though?

[vszakats]

Ultimately it's a "personal"/arbitrary choice. Since there as in "infinite" number of dynamic/static linkage combinations, I had to choose one and that's the one I choose after weighing pros/cons. My observation is that if a project chooses to use DLLs in the first place, the goal is to have all libs as DLL. This also saves space for curl-for-win (by not having to distro all dependent code as part of libcurl.dll as well, adding bloat). It's also the combination that can be built relatively cleanly because the libcurl.dll build doesn't need to know about the complete static lib dependency-tree at build-time. It also means that DLL users are free to update the dependencies separately (one main goal of using DLLs as I reckon). But, I never personally used DLLs on Windows and found little if any advantage using them, so maybe I'm assuming some things wrong (and there is nothing even close to a standard for any of this on Windows). I must have said similar things over at #12.

If the goal is to avoid DLLs, libcurl.dll included, it's possible to link everything statically. But, if the goal is to have libcurl.dll, but no other DLLs; that particular combination (along with different potential mixed static-DLL lib combinations) just isn't covered by curl-for-win.

[ FWIW the README says that curl.exe is offered as a standalone (aka static) binary. This wording is intentional to refer to the .exe only. ]

[vszakats]

After digging in the build sources, I realized that the small DLL dependencies are already linked statically to libcurl.dll (should have been obvious from the DLL deps output, yay). So, aside from potential technical difficulties resulting from linking OpenSSL statically as well (not sure I've ever tried doing that and there can be surprises), the only decision to make here is whether linking it statically would be the desired behaviour for most libcurl.dll users. What is lost, is the ability to update the OpenSSL DLLs independently from libcurl.dll, and the increased traffic/download size for the curl.se servers.

[bagder]

What is lost, is the ability to update the OpenSSL DLLs independently from libcurl.dll

My gut feeling says that users that download these binaries would download them from the same place anyway and thus would still get them in sync, in one file or several. I don't think linking with it statically in this build will upset many users. And I don't think we will find out either until we try it and see if anyone complains...

and the increased traffic/download size for the curl.se servers.

I don't want to say that bandwidth is free for us, but it practice it basically is since we have a sponsor for whom our bandwidth use is like a drop in the ocean.

[vszakats]

I'll make some tests with linking OpenSSL statically.

[vszakats]

Standalone libcurl*.dll is now available, version 7.75.0_1+.

Size increase almost nothing (+5%) for the TAR package, +35-38% for ZIP: pkg	7.75.0	7.75.0_1
curl-win32-mingw.tar.xz	2116716	2223528
curl-win32-mingw.zip	3271416	4448842
curl-win64-mingw.tar.xz	2283028	2395164
curl-win64-mingw.zip	3575937	4938635