OpenSSL DLLs required for `libcurl.dll` about curl-for-win

[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]

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

[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.

[vszakats]

I'll make some tests with linking OpenSSL statically.