Oops. This package uses libtool+auto{conf,make}. I do a `make install-strip` during the process of building a cygwin binary tarball, and I assumed that this auto-generated make target would strip any target that should be stripped, including .EXE's (it did) and .DLL's (it didn't).
Could this be a bug in automake and/or libtool? Is this stripping issue minor enough that I can just wait until the next release to fix it? Curl usually puts out new releases every few weeks, a couple months max. Or should it really be corrected immediately, and re-released as curl-7.9.1-2? If so, I'll be happy to make it so - just say the word. Also, I'm wondering if I made the right choice regarding SSL support in cURL. If SSL support is desired, it must be compiled that way (and -enable-ssl is the default). But since the cygwin OpenSSL package doesn't come with dynamic/shared libraries (e.g. no .DLL), I can't link dynamically against OpenSSL, therefore it gets statically linked. Something caught my eye today and made me wonder whether this creates either licensing and/or export issues. With that in mind, should I change the binary package so that it's only available in pre-compiled format withOUT SSL support, and require the user to download and recompile if they desire SSL support? The better solution (in my opinion) is if: a) The OpenSSL package could be tweaked to come with DLLs (the mingw32 binary available at curl.haxx.se has DLLs should it shouldn't be tough) b) We could somehow offer two pre-compiled versions of (lib)curl: with and without SSL support... --Kevin