Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Wed, 5 Feb 2003 11:18:22 -0600
From: Jay Maynard <jmaynard AT conmicro DOT cx>
To: cygwin AT cygwin DOT com
Subject: Re: Packaging software built with cygwin
Message-ID: <20030205111822.B9661@thebrain.conmicro.cx>
References: <20030204194653 DOT A5738 AT thebrain DOT conmicro DOT cx> <Pine DOT GSO DOT 4 DOT 44 DOT 0302042115170 DOT 24195-100000 AT slinky DOT cs DOT nyu DOT edu> <20030204204803 DOT A6191 AT thebrain DOT conmicro DOT cx> <20030205033246 DOT GA4959 AT redhat 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: <20030205033246.GA4959@redhat.com>; from cgf@redhat.com on Tue, Feb 04, 2003 at 10:32:46PM -0500

On Tue, Feb 04, 2003 at 10:32:46PM -0500, Christopher Faylor wrote:
> On Tue, Feb 04, 2003 at 08:48:03PM -0600, Jay Maynard wrote:
> >On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote:
> >>Remember that linking against some version of libcygwin.a doesn't mean
> >>you have to keep to the corresponding version of cygwin1.dll.  Since
> >>it's loaded dynamically, all you need is for the functions you need to
> >>be present in the new DLL.  This is generally the case.
> >Present *and* working the same or compatibly.  Unfortunately, we've
> >found that that's not the case.
> I sincerely doubt that you've found a problem where something that was
> available in an older DLL is not available in a newer one.  The only
> case I can think of where this happened is the dropping of //a for
> /cygdrive/a.

There are numerous bug reports in the Hercules mailing list archives from
folks who have tried to run Hercules with a different version of
cygwin1.dll than the one Hercules was built against. In every case,
installing the version that Hercules was built against corrected the
problem.

It may be intended to be upward compatible, but that's not our experience.

> >There's also a bug right now that causes allocation of three times as
> >much memory as Hercules actually calls for.  (I believe that one's
> >already been reported; it really hits Hercules hard, though, as it's
> >not uncommon to have Hercules allocate 256 MB of memory for the
> >emulated system's central storage, and a 768 MB allocation will drive
> >most Windows boxes to their knees.)
> I'm not aware of any bug report along these lines.  I must have missed
> it.
> A test case would be welcome.

I've asked the Hercules developer community, several of whom are much more
familiar with development under Cygwin than I am, to generate a test case
and report the bug. I had thought it had been reported, but it apparently
has not been.

> However, just in case you need to hear it, it is true that you have to
> provide the sources for the cygwin DLL if you want to distribute it.

I have stopped distributing the Cygwin DLL entirely, since meeting this
requirement would impose larger requirements for disk space and/or time than
I can afford. (See how the GPL has improved sharing of programs! Pfaugh.) Of
the five DLLs that Hercules needs (cygwin1.dll, cygintl-2.dll,
cygiconv-2.dll, cygbz2-1.dll, and cygz.dll), only one is GPLed. This imposes
requirements on distribution of the complete package that do not apply to
the other platforms that Hercules is distributed for. This is hardly going
to make porting packages from Linux to Windows easier.

I've considered, and rejected, the idea of distributing my own setup.ini
file. The problem is that it seems to be as much of a moving target as
Cygwin itself.

I would suggest that, if it is desired to promote the development of
applications on the Cygwin platform, serious consideration be made to making
it as simple as possible to install only those portions of Cygwin that the
application requires. This means just the necessary DLLs, without all of the
interactive use baggage. Right now, that's nearly impossible.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/