Re: Libcurl-win - linkage, redistributables

On 8/11/2020 10:54 AM, David Harris via curl-library wrote:
> I apologize if some or all of this is covered elsewhere - I*did* take a browse through the last
> few months of list archives to see if I could see anything, but nothing jumped out.
>
> First, a little context: I am in the process of developing support for the infinitely accursed
> "OAUTH2" authentication framework, specifically as it is used by GMail. I'm not going to
> waste everyone's time by ranting about OAUTH2 - suffice it to say that as part of the maze of
> steps required to make it work, I need some reliable HTTP client code. While I could write my
> own HTTP/HTTPS handlers, it seemed more logical to use a solid, proven tool like libCurl
> instead.
>
> I have run into three issues with LibCurl as it exists in the Windows environment, most of
> them to do with linkage. I'm hoping to get some insight into how best to deal with them.
>
> 1: Linking to dynamic RTLs. I've read the stuff in WinBuild about CRT linkage, but while I
> can understand why the decision might have been made to go with linking to the DLL RTL
> libraries, it's a problem for me. My program (Pegasus Mail) is pretty much a niche product
> these days, but it's used on practically every version of Windows that still runs. I've always
> static-linked to RTLs to avoid having to include MS redistributables in my installers: given that
> some of the redistributable packages are larger than my entire program, they constitute
> "bloat" on a level I find uncomfortable. Having to use a version of LibCurl that requires
> redistributables which will more than double the size of my distribution, all so I can do one
> badly-designed authentication protocol that's been shoved down our collective throats by
> people who should have been able to do better... Well, let's just say I've got problems with
> that idea.
>
> My inclination, then, is to build a version of LibCurl that uses the RTLIBCFG=static option, but
> this seems to be deprecated so heavily in WinBuild.txt that have to ask: is it really as
> untested and unreliable as WinBuild.txt seems to suggest? In a practical sense, am I really
> going to run into problems with this, or is the warning merely a case of excessive caution?
>
> 2: If I end up building static LibCurl, what libraries do I absolutely*have* to include for
> reasonable levels of operation? I already produce my own OpenSSL builds (for many of the
> same reasons I'm describing here - /MD linkage just won't work for me), but do I need things
> like NGHTTP2, C-ARES or ZLIB for basic HTTP operation? I don't imagine that those
> libraries will be any easier to build for Windows, so if this is going to turn into a major
> production exercise, it may end up being better for me to write my own simple HTTP code
> instead, given how limited my need is. This isn't intended to sound arrogant - I've written
> HTTP servers and both servers and clients for almost every mail protocol there's ever been,
> and I have very extensive TCP/IP code libraries, so I believe that simple HTTP client code
> should be manageable - but I'd sooner use LibCurl if I can, simply because it has such
> impeccable pedigree and because it offers real scope for growth.
>
> 3: What MS redistributable does the 7.71.1 build of LibCurl I downloaded from
> https://curl.haxx.se/windows/ require? Is the redistributable available anywhere on the site (I
> have access to Visual C 9, 14 and 19)?
>
> Please don't think I'm being negative - I would love to have Curl/LibCurl in my arsenal of
> tools, and once I had it working, I'm sure I would find more and more uses for it. I admire the
> authors, and love the richness - it's just the little niggles I have to sort out so I can work out
> how neat a fit it is for my purposes.

I assume you mean BUILD.WINDOWS.txt which says "RTLIBCFG is rarely used
and therefore rarely tested." That doesn't mean deprecated.

Your build should have at least SSL. I suggest use OpenSSL instead of
the native SSL (Schannel/WinSSL) because you want to run on older
versions of Windows and the native SSL on those older versions does not
support as many SSL protocols or algorithms. OTOH if size is your
primary concern maybe you should consider the native SSL, but you will
run the risk that as servers upgrade their TLS and older Windows doesn't
then your program may not be able to connect to those servers.

The official build of curl for Windows [1] uses the default CRT that
comes with the OS, msvcrt.dll, which is actually some specific version
of the CRT when the OS was shipped. It may be easier for you to consider
using that rather than include a copy of a specific CRT with your program.

There are several ways to build curl for Windows. If you build using
Visual Studio we do not have a configuration that uses the default OS
CRT (or maybe we do and I don't know about it?). Instead build using
mingw/msys.

[1]: https://github.com/curl/curl-for-win

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-08-12