curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Libcurl-win - linkage, redistributables

From: David Harris via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 12 Aug 2020 02:54:53 +1200

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.

Thanks in advance for any advice or opinions.

Cheers!

-- David --

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