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
Date: Mon, 19 Nov 2001 22:25:02 +0100
From: Corinna Vinschen <vinschen AT redhat DOT com>
To: cygwin-apps AT cygwin DOT com
Subject: Re: Shouldn't /bin/cygcurl-2.dll from curl-7.9.1-1 be stripped ?
Message-ID: <20011119222502.B15169@cygbert.vinschen.de>
Reply-To: cygwin-apps AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
References: <6EB31774D39507408D04392F40A10B2BC1FE10 AT FDYEXC202 DOT mgroupnet DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <6EB31774D39507408D04392F40A10B2BC1FE10@FDYEXC202.mgroupnet.com>; from KPRoth@MarathonOil.com on Mon, Nov 19, 2001 at 04:08:22PM -0500

On Mon, Nov 19, 2001 at 04:08:22PM -0500, Roth, Kevin P. wrote:
> 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.

I think it's ok to wait.

> 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?

Think it that way:  We couldn't offer OpenSSH on the server if that
would have been an issue.  The release of OpenSSL on the sourceware
server is officially registered at the... uhm... whatever the name of
that government is in the US.  Something with "export" in the name.
Please keep the package using OpenSSL.

> 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)

Sigh.  I'm not that keen to do that.  It makes extra work which I
don't like at all...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin AT cygwin DOT com
Red Hat, Inc.