Shouldn't /bin/cygcurl-2.dll from curl-7.9.1-1 be stripped ?

Roth, Kevin P.
Tue Nov 13 18:37:00 GMT 2001

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

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 has DLLs should it shouldn't be

 b) We could somehow offer two pre-compiled versions of (lib)curl: with
    and without SSL support...


More information about the Cygwin-apps mailing list