use system libcurl with MSYS2/MINGW64?

[ian-p-cooke]

can curl-sys/build.rs use pkg-config for x86_64-pc-windows-gnu? right now there's an explicit check in build.rs for a windows target that skips pkg-config but I don't understand why that's there. At least for my MSYS2/MINGW64 install (Windows 10) pkg-config works fine and curl-sys can build with that.

I got on this path because I was building cargo and getting a bunch of OpenSSL linking errors... it seemed like libcurl was building with my system openssl but not statically linking it. Then I was like, "why is it building libcurl at all?" So I cloned curl-rust, removed that condition, added a patch section to cargo's Cargo.toml to use my curl-rust and curl-sys and then it worked out. So maybe that lack of static linking is a second issue but using pkg-config would help me more.

[alexcrichton]

pkg-config has a pretty bad track record of working on Windows from what I've seen, but it seems reasonable to at least add some sort of env var or configuration to enable it

[ian-p-cooke]

I see. In fact, I have to take a step back and qualify my previous 'works fine' statement: it works fine if you want to link to it dynamically. I haven't been able to get a statically linked executable when using the packaged curl. I think the packaged curl's .a is not itself statically linked to its dependencies because I'm getting some __imp_SYMBOL not defined errors with, for example, nghttp2 symbols. I'm futzing with the package and don't see it actually using the "-DCURL_STATICLIB -DNGHTTP2_STATIC" flags at all when I make --trace it.

I'll try and get static linking against the pkg-config discovered libcurl working over the weekend... I'm deep down a rabbit hole of getting a new Windows 10 laptop set up for dev work and I keep getting blocked on one thing or another no matter which path I go down. If I can't get that working then I'll go back to figuring out the linking errors I get when I allow curl-rust to build its own libcurl.

[ian-p-cooke]

I gave up on building a windows-gnu statically linked curl-rust against the packaged libcurl. Instead I built curl-rust using the msvc toolchain and called it a day. This was good enough for what I wanted (a new build of cargo for windows that worked from CMD). I don't think the MINGW package is building the static library correctly and even if it was able to get nghttp2 linked in as they intended there are other dependencies that need to be statically linked (e.g. openssl, brotli, z).

If I'm right about the package being busted for static linking, I don't recommend completing this feature unless you want to work on submitting a patch for the mingw package itself.

You may close this issue as far as I'm concerned.

[alexcrichton]

Ok!