Thanks for your response! On 11/9/21 15:04, Daniel Stenberg wrote:
Having configure checks fail to detect something optional is not a problem
Well, it is a problem if what it fails on is what I want to use, which was the case here.
> If you want to use OpenSSL, why point it to a fake install and not a real install?
I was under the assumption I can't install a Windows OpenSSL on a Linux host. To be fair, I didn't actually try so maybe I should, good point. Still seems like a bit of a nonsensical workflow though. Why do I need an install when all I want is a static build with a static link that should only need the header files?
> You could basically just remove all the --without-* options from this command line and it would still give the same end result.
So using none of these libraries EVEN IF PRESENT is the default? I don't think I saw that behavior, but I can check again if you're sure about that. (To elaborate, the problem is even if they're present on my system they won't on the end user's, so I can't just have it randomly pick those up because it gives me a broken build. But blacklisting it all with those --without is both ugly, and a maintenance nightmare since I assume new external libs & features are added frequently.)
I have also noticed as a side note that for a Windows build with autotools, it seems to be impossible to avoid including code that needs a link to crypt32/wincrypt, even when I want to use OpenSSL & custom cert store only. If there is an option to prevent that I didn't find it. This is somewhat relevant to me because I'm about to try a Windows XP-compatible build, so having unnecessary exposure to WinAPI of things I don't want it to use anyway is a bit of a liability (although might not be an issue in practice, I'll know soon after tests).
Regards, Ellie -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
