Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Shouldn't /bin/cygcurl-2.dll from curl-7.9.1-1 be stripped ?
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
Date: Mon, 19 Nov 2001 16:08:22 -0500
Message-ID: <6EB31774D39507408D04392F40A10B2BC1FE10@FDYEXC202.mgroupnet.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Shouldn't /bin/cygcurl-2.dll from curl-7.9.1-1 be stripped ?
Thread-Index: AcFxMUsq8laD9D78S+iBXJ5sR4ttcQABu2LA
From: "Roth, Kevin P." <KPRoth AT MarathonOil DOT com>
To: "Dr. Volker Zell" <Dr DOT Volker DOT Zell AT oracle DOT com>, <cygwin-apps AT cygwin DOT com>
X-OriginalArrivalTime: 19 Nov 2001 21:09:42.0712 (UTC) FILETIME=[82109380:01C1713E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id fAJL9kv23845

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