Packaging software built with Cygwin

Packaging software built with Cygwin

[Jay Maynard]

This is probably an FAQ, but I haven't been able to find any answers on the
FAQ page at cygwin.com.

I'm the maintainer of Hercules, an emulator for IBM mainframe systems that
runs on Linux, Mac OS X, and other Unix-style OSes, and Windows via Cygwin.
It's distributed under an OSD-compliant license (the QPL).

Currently, we distribute the package without any Cygwin DLLs. Many of our
users would like to install Hercules and the necessary DLLs without having
to install of Cygwin, or any more than they have to; they're not interested
in the Cygwin environment more than is required to run Hercules. Further,
since Cygwin is such a moving target, I'd like to be able to give the users
an easy way to install the version of the DLLs that corresponds to the
version of Cygwin which I used to build the package.

Under what terms can I distribute the DLLs? Can I just build up a .zip file
with the required files and a copy of the GPL, or will I have to maintain
multiple versions of the source code for download as well? (If the latter,
I'll probably blow it off entirely; I don't have that kind of disk space.)
If I can't distribute the files themselves, is there a simple way to
distribute a file that can be fed to setup.exe that will result in only the
needed files being downloaded?

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

Re: Packaging software built with Cygwin

[Igor Pechtchanski]

On Tue, 4 Feb 2003, Jay Maynard wrote:

> This is probably an FAQ, but I haven't been able to find any answers on the
> FAQ page at cygwin.com.
>
> I'm the maintainer of Hercules, an emulator for IBM mainframe systems that
> runs on Linux, Mac OS X, and other Unix-style OSes, and Windows via Cygwin.
> It's distributed under an OSD-compliant license (the QPL).
>
> Currently, we distribute the package without any Cygwin DLLs. Many of our
> users would like to install Hercules and the necessary DLLs without having
> to install of Cygwin, or any more than they have to; they're not interested
> in the Cygwin environment more than is required to run Hercules. Further,
> since Cygwin is such a moving target, I'd like to be able to give the users
> an easy way to install the version of the DLLs that corresponds to the
> version of Cygwin which I used to build the package.
>
> Under what terms can I distribute the DLLs? Can I just build up a .zip file
> with the required files and a copy of the GPL, or will I have to maintain
> multiple versions of the source code for download as well? (If the latter,
> I'll probably blow it off entirely; I don't have that kind of disk space.)
> If I can't distribute the files themselves, is there a simple way to
> distribute a file that can be fed to setup.exe that will result in only the
> needed files being downloaded?

Jay,

You are aware that linking against the Cygwin DLL automatically makes your
software GPL'ed, right?  And you are also aware that, if you distribute
the Cygwin DLL, you have to distribute it with the source used to build
it, correct?

However, you don't have to maintain multiple versions of the source code -
only the source of the cygwin DLL that you distribute.  Thus, if you
always update the cygwin DLL on your mirror to the latest available one,
you can keep only one (the latest) version of the source there.

To answer your last question, setup.exe uses a file called setup.ini,
the format of which is described at <http://sources.redhat.com/cygwin-apps/setup.html>
(but be sure to use the format for the correct setup version).  You can
set all the packages you want installed to the "Base" category, so the
users can simply point their setup.exe to your mirror and click "Install".

However, as the case with NetworkSimplicity's ssh product showed, it's not
a good idea to distribute your own cygwin1.dll, especially if you put it
in a non-standard location or modify it in any way, as it falls out of
date with the "official" cygwin1.dll...

But don't despair.  You can do even better than that.  You don't have to
distribute the cygwin DLL from your mirror *at all*.  All you need to do
is include the "cygwin" package and the others you need in the "requires"
list for your ("hercules"?) package, and instruct the users to select one
of the standard mirrors along with yours in the setup mirror list.  Then,
when they select your package to be installed (which would happen
automatically if you put it in the "Base"  category in your setup.ini),
all the packages that it depends upon (i.e., those in its "requires" list)
will also be installed.  Of course, this will install all of the
"standard" "Base" category, but it's not that large, and, chances are,
your package depends on most of it anyway.  All you'll have to do is make
sure that your package works with the latest cygwin1.dll... ;-)

Hope this made sense,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


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

Re: Packaging software built with Cygwin

[Jay Maynard]

On Tue, Feb 04, 2003 at 06:27:39PM -0500, Igor Pechtchanski wrote:
> You are aware that linking against the Cygwin DLL automatically makes your
> software GPL'ed, right?

Not according to http://cygwin.com/licensing.html:

"In accordance with section 10 of the GPL, Red Hat permits programs whose
sources are distributed under a license that complies with the Open Source
Definition to be linked with libcygwin.a without libcygwin.a itself causing
the resulting program to be covered by the GNU GPL."

If, despite this, Hercules is somehow covered by the GPL, then our only
choice will be to stop distributing a Cygwin version of Hercules, in either
source or binary form, as relicensing Hercules under the GPL will never
happen.

> And you are also aware that, if you distribute the Cygwin DLL, you have to
> distribute it with the source used to build it, correct?

If that's the case, then I won't distribute the DLLs. I can't afford to keep
around multiple versions of the source code corresponding with the multiple
versions of the DLLs needed for multiple versions of Hercules.

> However, you don't have to maintain multiple versions of the source code -
> only the source of the cygwin DLL that you distribute.  Thus, if you
> always update the cygwin DLL on your mirror to the latest available one,
> you can keep only one (the latest) version of the source there.

Unfortunately, I keep multiple versions of Hercules around. Since each
version of Hercules is compiled against a different version of Cygwin, that
means that I need to keep the corresponding DLLs around (since mixing them
has proven to be problematical), and that means I need to keep the source,
too.

> But don't despair.  You can do even better than that.  You don't have to
> distribute the cygwin DLL from your mirror *at all*.  All you need to do
> is include the "cygwin" package and the others you need in the "requires"
> list for your ("hercules"?) package, and instruct the users to select one
> of the standard mirrors along with yours in the setup mirror list.

Erf. This assumes that the user will use the Cygwin setup routine to install
Hercules. So far, there's been no need for that. Hercules is intended as a
standalone package which can run with only the required DLLs installed, and
none of the rest of Cygwin. The Hercules distribution is a self-extracting
.ZIP, self-contained.

> all the packages that it depends upon (i.e., those in its "requires" list)
> will also be installed.  Of course, this will install all of the
> "standard" "Base" category, but it's not that large, and, chances are,
> your package depends on most of it anyway.  All you'll have to do is make
> sure that your package works with the latest cygwin1.dll... ;-)

In general, when cygwin1.dll changes, Hercules breaks.

> Hope this made sense,

It did, but I'm not sure there's a lot of help there...

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

Re: Packaging software built with Cygwin

[Igor Pechtchanski]

On Tue, 4 Feb 2003, Jay Maynard wrote:

> On Tue, Feb 04, 2003 at 06:27:39PM -0500, Igor Pechtchanski wrote:
> > You are aware that linking against the Cygwin DLL automatically makes your
> > software GPL'ed, right?
>
> Not according to http://cygwin.com/licensing.html:
>
> "In accordance with section 10 of the GPL, Red Hat permits programs whose
> sources are distributed under a license that complies with the Open Source
> Definition to be linked with libcygwin.a without libcygwin.a itself causing
> the resulting program to be covered by the GNU GPL."
>
> If, despite this, Hercules is somehow covered by the GPL, then our only
> choice will be to stop distributing a Cygwin version of Hercules, in either
> source or binary form, as relicensing Hercules under the GPL will never
> happen.

Now, hold on there, no need to jump the gun.  I'm not what you may call "a
definitive expert on Cygwin licensing".  In fact, whatever that page says
surely overrides what I said earlier.

> > And you are also aware that, if you distribute the Cygwin DLL, you have to
> > distribute it with the source used to build it, correct?

I'm pretty sure of this one, but the definitive answer should probably be
given by Chris Faylor...

> If that's the case, then I won't distribute the DLLs. I can't afford to keep
> around multiple versions of the source code corresponding with the multiple
> versions of the DLLs needed for multiple versions of Hercules.

And why is that?  Cygwin DLL is supposed to be backward compatible, either
directly or through options.  I'd be surprised if any functionality was
actually *missing* from a newer cygwin1.dll that was present in an older
release (except for the stuff that "nobody used" which got taken out -- if
you did use it, you should speak up for including it back in).

> > However, you don't have to maintain multiple versions of the source code -
> > only the source of the cygwin DLL that you distribute.  Thus, if you
> > always update the cygwin DLL on your mirror to the latest available one,
> > you can keep only one (the latest) version of the source there.
>
> Unfortunately, I keep multiple versions of Hercules around. Since each
> version of Hercules is compiled against a different version of Cygwin, that
> means that I need to keep the corresponding DLLs around (since mixing them
> has proven to be problematical), and that means I need to keep the source,
> too.

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.

> > But don't despair.  You can do even better than that.  You don't have to
> > distribute the cygwin DLL from your mirror *at all*.  All you need to do
> > is include the "cygwin" package and the others you need in the "requires"
> > list for your ("hercules"?) package, and instruct the users to select one
> > of the standard mirrors along with yours in the setup mirror list.
>
> Erf. This assumes that the user will use the Cygwin setup routine to install
> Hercules. So far, there's been no need for that. Hercules is intended as a
> standalone package which can run with only the required DLLs installed, and
> none of the rest of Cygwin. The Hercules distribution is a self-extracting
> .ZIP, self-contained.

Oh.  In that case, yes, you'll either need to distribute the cygwin1.dll
yourself (and make the source available somewhere) or have the users
install the required packages via setup.  I assumed you were asking about
the latter, hence the answer.  The "hercules" package that I was talking
about doesn't actually have to contain anything except the dependences (or
it could contain a post-install script that would install Hercules from a
separately downloaded .ZIP/.EXE or configure an already installed one).

You may also want to take a look at CVS HEAD setup's command-line options
(only in the source in CVS at the moment, sorry).

> > all the packages that it depends upon (i.e., those in its "requires" list)
> > will also be installed.  Of course, this will install all of the
> > "standard" "Base" category, but it's not that large, and, chances are,
> > your package depends on most of it anyway.  All you'll have to do is make
> > sure that your package works with the latest cygwin1.dll... ;-)
>
> In general, when cygwin1.dll changes, Hercules breaks.

Why?

> > Hope this made sense,
>
> It did, but I'm not sure there's a lot of help there...

Sorry to hear that.  AFAIK, you do have to provide sources for the
cygwin1.dll that you distribute.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


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

Re: Packaging software built with Cygwin

[Jay Maynard]

On Tue, Feb 04, 2003 at 09:31:43PM -0500, Igor Pechtchanski wrote:
> Now, hold on there, no need to jump the gun.  I'm not what you may call "a
> definitive expert on Cygwin licensing".  In fact, whatever that page says
> surely overrides what I said earlier.

Okkay...that's what I'd been relying on, and hearing that it wasn't true
after all was a shock. I'm happy to hear that my original understanding was
correct.

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

> Oh.  In that case, yes, you'll either need to distribute the cygwin1.dll
> yourself (and make the source available somewhere) or have the users
> install the required packages via setup.  I assumed you were asking about
> the latter, hence the answer.  The "hercules" package that I was talking
> about doesn't actually have to contain anything except the dependences (or
> it could contain a post-install script that would install Hercules from a
> separately downloaded .ZIP/.EXE or configure an already installed one).

Well, if there was an easy way to get setup to do the job, that would be
okkay (as long as I could include setup and the necessary control files in
the Hercules .ZIP). It sounds like there's not.

> > In general, when cygwin1.dll changes, Hercules breaks.
> Why?

I wish I knew. In general, though, Hercules seems to be a stress test for
Cygwin, and we've had lots of folks have trouble by installing later
versions fo the DLL than Hercules was built with. 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.) When that one gets
fixed, I'm expecting to have to update my copy of Cygwin, then distribute
updated Hercules binaries - which will mean updating the copy of cygwin1.dll
needed, which will mean either adding another version of the source (all N
megabytes of it), or else pointing people to the Cygwin site...

Maybe a better idea is to have a setup option that installs needed DLLs
*only*, with no shell, no utility programs, etcetera.

> Sorry to hear that.  AFAIK, you do have to provide sources for the
> cygwin1.dll that you distribute.

Damn. You know, this is one reason people stay away from the GPL...
(I can go on for hours, and there are undoubtedly folks here who have heard
me do it. Anyone who would like to get the whole rant is invited to contact
me off-list.)

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

Re: Packaging software built with cygwin

[Christopher Faylor]

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:
>>Now, hold on there, no need to jump the gun.  I'm not what you may call
>>"a definitive expert on Cygwin licensing".  In fact, whatever that page
>>says surely overrides what I said earlier.
>
>Okkay...that's what I'd been relying on, and hearing that it wasn't
>true after all was a shock.  I'm happy to hear that my original
>understanding was correct.

If you are distributing something that satisfies the "open source"
requirement then the program doesn't have to be GPLed.  If the QPL is
OSD-compliant, as you said, then there is no problem.

>>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'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.

>> Sorry to hear that.  AFAIK, you do have to provide sources for the
>> cygwin1.dll that you distribute.
>
>Damn. You know, this is one reason people stay away from the GPL...
>(I can go on for hours, and there are undoubtedly folks here who have heard
>me do it. Anyone who would like to get the whole rant is invited to contact
>me off-list.)

Thank you for showing restraint and not going on for hours.

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.

cgf

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

Re: Packaging software built with cygwin

[Nigel Stewart & Fiona Smith]

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

	There is always the MingW option via -mno-cygwin.
	(Perhaps stating the obvious, but just in case...)

	http://www.mingw.org/

Regards,

Nigel Stewart


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

Re: Packaging software built with cygwin

[Christopher Faylor]

On Thu, Feb 06, 2003 at 12:39:45AM +1100, Nigel Stewart & Fiona Smith wrote:
>>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.
>
>There is always the MingW option via -mno-cygwin.  (Perhaps stating the
>obvious, but just in case...)
>
>http://www.mingw.org/

I assume that the software in question actually uses the UNIX api.  Mingw has
only a very small subset of this available.

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

Re: Packaging software built with cygwin

[Jay Maynard]

On Wed, Feb 05, 2003 at 09:12:02AM -0500, Christopher Faylor wrote:
> On Thu, Feb 06, 2003 at 12:39:45AM +1100, Nigel Stewart & Fiona Smith wrote:
> >>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.
> >There is always the MingW option via -mno-cygwin.  (Perhaps stating the
> >obvious, but just in case...)
> >http://www.mingw.org/
> I assume that the software in question actually uses the UNIX api.  Mingw has
> only a very small subset of this available.

Hercules uses large parts of the Linux API. (It was originally developed on
Linux; while it'll run on most Unix systems, there are some functions, most
notably SCSI tape support, that only work on Linux.)

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

Re: Packaging software built with cygwin

[Jay Maynard]

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/

Re: Packaging software built with cygwin

[Nigel Stewart & Fiona Smith]

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

	Technically, the ideal solution would be to link against a set
	of static libraries.  Therefore requiring no extra install at
	all.  No DLL hell, no tech support, no "Cygwin is the problem"
	perception.  However, is it feasible for the Cygwin project to
	make this exception for the sake of utility?

	This is the same reason I find myself experimenting with
	mingw, I would like to use Cygwin as the devel platform
	and target native binaries, or at least non Cygwin-DLL
	dependent binaries...

	My 0.02, no offence intended to GPL oriented people...

Regards,

Nigel Stewart


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

Re: Packaging software built with cygwin

[Max Bowsher]

Nigel Stewart & Fiona Smith wrote:
>> 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.

If someone wishes to volunteer to work towards that...

> Technically, the ideal solution would be to link against a set
> of static libraries.  Therefore requiring no extra install at
> all.  No DLL hell, no tech support, no "Cygwin is the problem"
> perception.

I believe this would require some significant work to make it possible.

> However, is it feasible for the Cygwin project to
> make this exception for the sake of utility?

If you are talking about making cygwin static-capable - see above - lots of
work. Also, the most experienced Cygwin coders won't be that interested,
because they *like* Cygwin-the-enviroment, as opposed to
Cygwin-for-the-sake-of-one-program.

Also, there is the side benefit that it is *much* easier to spot GPL
violations this way.

> This is the same reason I find myself experimenting with
> mingw, I would like to use Cygwin as the devel platform
> and target native binaries, or at least non Cygwin-DLL
> dependent binaries...

You can - they just can't use the unix APIs.
I use Cygwin for all my compilation needs, Cygwin-linked, or native Win32.

Max.


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

Re: Packaging software built with cygwin

[Nigel Stewart & Fiona Smith]

>>Technically, the ideal solution would be to link against a set
>>of static libraries. 
> 
> I believe this would require some significant work to make it possible.

	OK, it feels like we're getting into a circular
	argument.  I am not insisting that anyone do
	any particular thing to Cygwin.  My intention
	is to raise a perspective on a potential use
	of Cygwin which may or may not be desirable,
	feasible, popular or supported by the Cygwin
	community.

> Also, the most experienced Cygwin coders won't be that interested,
> because they *like* Cygwin-the-enviroment, as opposed to
> Cygwin-for-the-sake-of-one-program.

	Fair enough, I like using Cygwin-the-environment, but
	feel restricted in terms of deploying binaries into
	a non-cygwin environment.  Even though the Cygwin
	installation procedure has been greatly enhanced and
	streamlined, in my opinion Cygwin is too heavy-weight for
	an average computer user to install and administer.

	So, if this is outside the scope of what Cygwin is
	for, then that is a reasonable answer...  I'm finding
	mingw is working quite well (perhaps, the best of both
	worlds) but would prefer to keep my code clean (POSIX)
	rather than infected with extraneous win32 calls...

> You can - they just can't use the unix APIs.
> I use Cygwin for all my compilation needs, Cygwin-linked, or native Win32.

	So rather than upsetting the Cygwin faithful, would
	it be better to expand the support POSIX subset for
	mingw, rather than making Cygwin an easily managed
	light-weight dependency.

Regards,

Nigel Stewart


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

Re: Packaging software built with cygwin

[Max Bowsher]

Nigel Stewart & Fiona Smith wrote:
> Fair enough, I like using Cygwin-the-environment, but
> feel restricted in terms of deploying binaries into
> a non-cygwin environment.  Even though the Cygwin
> installation procedure has been greatly enhanced and
> streamlined, in my opinion Cygwin is too heavy-weight for
> an average computer user to install and administer.

I agree that Cygwin is a very bulky solution if you only want to be able to
run one program (ssh, or rsync, for example).

> So rather than upsetting the Cygwin faithful, would
> it be better to expand the support POSIX subset for
> mingw, rather than making Cygwin an easily managed
> light-weight dependency.

Those are 2 different paths to the same goal. However, if you worked at it
from the Cygwin end, the resulting code would be GPL.

Max.


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

Re: Packaging software built with cygwin

[Nigel Stewart & Fiona Smith]

> Those are 2 different paths to the same goal. 

	Just to clarify my "goal"....

	Painless development and deployment of
	software across Linux and Windows.
	Both open-source and commercial.

	Which, for me is already 95% there
	with Cygwin, and possibly even
	98% there with Cygwin+Mingw....

	Cheers,

	Nigel Stewart

	(Perhaps time to delve more into MingW :-)


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

Re: Packaging software built with cygwin

[Christopher Faylor]

On Thu, Feb 06, 2003 at 04:31:15AM +1100, Nigel Stewart & Fiona Smith wrote:
>>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.
>
>Technically, the ideal solution would be to link against a set of
>static libraries.  Therefore requiring no extra install at all.  No DLL
>hell, no tech support, no "Cygwin is the problem" perception.  However,
>is it feasible for the Cygwin project to make this exception for the
>sake of utility?

It isn't a question of "making an exception".  It's a question of
someone doing the work.  I have no interest in it and it seems like no
one else is either since this has come up repeatedly in the last five
years.

If you are asking if we'd make an exception and not GPL something because
it is statically linked then the answer to that is "no".  Static linking
doesn't change this scenario a whit.

>This is the same reason I find myself experimenting with mingw, I would
>like to use Cygwin as the devel platform and target native binaries, or
>at least non Cygwin-DLL dependent binaries...

If you want binaries that don't use the UNIX API then of course you
should use MinGW.  That has nothing to do with with licensing issues.

cgf

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

Re: Packaging software built with cygwin

[Christopher Faylor]

On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote:
>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.

Ok.  I'm not going to start scouring random other mailing lists for
cygwin bug reports so I suppose this situation will continue In absence
of any details, it's fruitless to carry this discussion any further.

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

Hmm.  Looks like you just couldn't resist, huh?

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

The source tarball for cygwin is 4.6M.  I don't understand why this
is a huge hardship but, frankly, I don't really care.

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

A setup.ini with just the cygwin DLL in it seems pretty simple.

Btw, perhaps it is not your intention, but I catch a whiff of innuendo
here makes me wonder if you're really asking for help or just here to
make some statements.

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

Supporting other people's distributions is not a core focus of
setup.exe.  However, if this is important to you it should be pretty
easy for you to submit patches to do what you want.

cgf

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

Re: Packaging software built with cygwin

[Jay Maynard]

On Wed, Feb 05, 2003 at 12:55:43PM -0500, Christopher Faylor wrote:
> On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote:
> >It may be intended to be upward compatible, but that's not our experience.
> Ok.  I'm not going to start scouring random other mailing lists for
> cygwin bug reports so I suppose this situation will continue In absence
> of any details, it's fruitless to carry this discussion any further.

Fine by me; it's been over the past year or so, as well, so bug reports at
this point will be of limited use. However, are you saying that if we
encounter problems with Hercules 2.17 (built against Cygwin 1.3.19) running
with, say, Cygwin 1.3.22, you'll take a bug report on that and fix the
problem?

BTW, I'm not the only one to have this problem; there's a message on the
Hercules list that was posted in reply to my announcement that I would no
longer distribute the DLLs saying that his company got away from Cygwin for
exactly that reason. (I'll forward it, if you like.)

> Hmm.  Looks like you just couldn't resist, huh?

No, I couldn't.

> The source tarball for cygwin is 4.6M.  I don't understand why this
> is a huge hardship but, frankly, I don't really care.

4.6 MB times how many versions will I need to keep around? Before I removed
them from the Hercules site, I had four sets of the Cygwin DLLs,
corresponding to four versions of Hercules they were needed for. Every time
I release a new version of Hercules, that's another source tarball I'd need.

Further, is that tarball guaranteed to satisfy the requirement to distribute
the source code for that version? Is everything that's needed in that one
tarball? If so, can I get that in writing, so that if someone comes along
later and alleges a GPL violation, I can say, "No, Red Hat says that
distributing this tarball is sufficient."? Otherwise, I'd have to keep
around the entire Cygwin source, just to make sure I included everything
that was necessary. I'm sure that's more than 4.6 MB.

> A setup.ini with just the cygwin DLL in it seems pretty simple.

True. OTOH, when setup.exe changes, the format of that file is subject to
change (see Igor's warning in the message where he first suggested that). I
can insulate myself from that by distributing setup.exe, but then I'm back
in the same boat of making sure that I distribute the source code that's
used to generate it.

> Btw, perhaps it is not your intention, but I catch a whiff of innuendo
> here makes me wonder if you're really asking for help or just here to
> make some statements.

I'm looking for a way to make it simple for Hercules users to install the
needed support for the Cygwin version without violating any licenses,
without having to keep multiple megabytes of multiple versions of source
code around that nobody will ever download, and without making them install
multiple megabytes of Cygwin environment they have no interest in using.

It's no secret that I've opposed the GPL for many years. (I invented the
term GPV in 1989.) However, I'm stuck with it, so I'm trying to do what I
need done without violating it. That doesn't mean I have to like it.

> Supporting other people's distributions is not a core focus of
> setup.exe.  However, if this is important to you it should be pretty
> easy for you to submit patches to do what you want.

I'll take a look in my copious free time.

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

Re: Packaging software built with cygwin

[Christopher Faylor]

Cutting through the noise:

1) In an open source, volunteer project there are no guarantees that
   anything will be fixed.  We do the best we can given our interests
   and time.  However, you should be reporting cygwin bugs to the cygwin
   mailing list if you want the possibility of getting them fixed.  You
   can use http://cygwin.com/bugs.html as a guide for how to submit bugs.

   No, I don't care to hear from the multitude of people in your project
   who are leaving cygwin because of all of their serious problems.  Good
   luck to them with MinGW, Interix, U/WIN, or whereever they've decided
   to use.  I'm only interested in actual bug reports.  I can do something
   with a bug report.  I can't do a single thing with "Every cygwin release
   breaks Hercules" or "Cygwin has too many bugs, so I'm giving up on it".

   I'm sure you know that neither of the above are bug reports.  They are
   basically just noise.  I don't have enough "copious spare time" to devote
   to wheedling details out of people.  YMMV.

2) I am not trying to blindside you by suggesting that you can distribute
   the Cygwin source tar ball so that Red Hat lawyers could go after you later.
   No, I'm not going to give you anything in writing.  I'm not going to
   set that precedent.  There are plenty of sites on the internet who are
   distributing the source tarballs without an official signature from Red Hat.

3) I find all GPL discussions uninteresting and unproductive.  I really really
   hope you can avoid any more harping on this.

4) I'm sorry that none of the suggestions put forth here are satisfactory
   to you.  I'm out of ideas, so that will probably be it for me in this
   thread unless there is a specific bug report that needs addressing.
   
cgf

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

Re: Packaging software built with cygwin

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

On Thu, 2003-02-06 at 05:55, Jay Maynard wrote:


> > A setup.ini with just the cygwin DLL in it seems pretty simple.
> 
> True. OTOH, when setup.exe changes, the format of that file is subject to
> change (see Igor's warning in the message where he first suggested that). I
> can insulate myself from that by distributing setup.exe, but then I'm back
> in the same boat of making sure that I distribute the source code that's
> used to generate it.

We're in that boat too. (I'm the setup.exe maintainer). And we don't
break compatability at any significant speed - we *alway* deprecate for
at least one release, to allow third party sites (ones with their own
custom setup.ini) to catch up in their own time.

For instance, uncompressed setup.ini's are still supported, as a
fallback when .bz2 compressed ones are not found.

As far as distributing multiple versions of setup.exe's source, it's
easy: only distribute the current version. You don't need to distribute
old versions, because you can just update your setup.ini.


> > Supporting other people's distributions is not a core focus of
> > setup.exe.  However, if this is important to you it should be pretty
> > easy for you to submit patches to do what you want.
> 
> I'll take a look in my copious free time.

Do that. There is very little that would need doing, if I intuit your
needs correctly.

Rob
-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Packaging software built with cygwin

[Ronald Landheer-Cieslak]

The way I read GPL (but please correct me if I'm wrong) you should be able 
to write a fork off the current Setup that installs the Hercules and gets 
the Cygwin from one of the mirrors (of which you can download the list at 
the time of installing from cygwin.com). Technically, you would not be 
distributing Cygwin (because you would be using Red Hat's own 
distribution) but the effect would be the same.

Your remaining problem would be that Cygwin is a "moving target" as you
say, but Cygwin doesn't move all *that* quickly either, does it? I mean,
you don't build Hercules against the latest snapshot do you? Of course, I
have no idea how extensively you use the Cygwin API but my (arguably
little, juding by the size of my projects vs yours) experience has always 
been that if you stick to POSIX compliance, Cygwin does the job quite 
nicely (and patches to Cygwin are usually welcome in case of error, 
provided you have a copyright waiver which I don't have).

As for GPL rants: I'd be interested (off-list) in hearing your reasons for 
being against GPL, and even more in what alternatives you would propose.

Greetz!

rlc

On Wed, 5 Feb 2003, Jay Maynard wrote:
> On Wed, Feb 05, 2003 at 12:55:43PM -0500, Christopher Faylor wrote:
> > On Wed, Feb 05, 2003 at 11:18:22AM -0600, Jay Maynard wrote:
> > >It may be intended to be upward compatible, but that's not our experience.
> > Ok.  I'm not going to start scouring random other mailing lists for
> > cygwin bug reports so I suppose this situation will continue In absence
> > of any details, it's fruitless to carry this discussion any further.
> 
> Fine by me; it's been over the past year or so, as well, so bug reports at
> this point will be of limited use. However, are you saying that if we
> encounter problems with Hercules 2.17 (built against Cygwin 1.3.19) running
> with, say, Cygwin 1.3.22, you'll take a bug report on that and fix the
> problem?
> 
> BTW, I'm not the only one to have this problem; there's a message on the
> Hercules list that was posted in reply to my announcement that I would no
> longer distribute the DLLs saying that his company got away from Cygwin for
> exactly that reason. (I'll forward it, if you like.)
> 
> > Hmm.  Looks like you just couldn't resist, huh?
> 
> No, I couldn't.
> 
> > The source tarball for cygwin is 4.6M.  I don't understand why this
> > is a huge hardship but, frankly, I don't really care.
> 
> 4.6 MB times how many versions will I need to keep around? Before I removed
> them from the Hercules site, I had four sets of the Cygwin DLLs,
> corresponding to four versions of Hercules they were needed for. Every time
> I release a new version of Hercules, that's another source tarball I'd need.
> 
> Further, is that tarball guaranteed to satisfy the requirement to distribute
> the source code for that version? Is everything that's needed in that one
> tarball? If so, can I get that in writing, so that if someone comes along
> later and alleges a GPL violation, I can say, "No, Red Hat says that
> distributing this tarball is sufficient."? Otherwise, I'd have to keep
> around the entire Cygwin source, just to make sure I included everything
> that was necessary. I'm sure that's more than 4.6 MB.
> 
> > A setup.ini with just the cygwin DLL in it seems pretty simple.
> 
> True. OTOH, when setup.exe changes, the format of that file is subject to
> change (see Igor's warning in the message where he first suggested that). I
> can insulate myself from that by distributing setup.exe, but then I'm back
> in the same boat of making sure that I distribute the source code that's
> used to generate it.
> 
> > Btw, perhaps it is not your intention, but I catch a whiff of innuendo
> > here makes me wonder if you're really asking for help or just here to
> > make some statements.
> 
> I'm looking for a way to make it simple for Hercules users to install the
> needed support for the Cygwin version without violating any licenses,
> without having to keep multiple megabytes of multiple versions of source
> code around that nobody will ever download, and without making them install
> multiple megabytes of Cygwin environment they have no interest in using.
> 
> It's no secret that I've opposed the GPL for many years. (I invented the
> term GPV in 1989.) However, I'm stuck with it, so I'm trying to do what I
> need done without violating it. That doesn't mean I have to like it.
> 
> > Supporting other people's distributions is not a core focus of
> > setup.exe.  However, if this is important to you it should be pretty
> > easy for you to submit patches to do what you want.
> 
> I'll take a look in my copious free time.
> 
> --
> 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/
> 


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

Re: Packaging software built with cygwin

[Jay Maynard]

On Thu, Feb 06, 2003 at 10:34:36AM +0100, Ronald Landheer-Cieslak wrote:
> The way I read GPL (but please correct me if I'm wrong) you should be able 
> to write a fork off the current Setup that installs the Hercules and gets 
> the Cygwin from one of the mirrors (of which you can download the list at 
> the time of installing from cygwin.com). Technically, you would not be 
> distributing Cygwin (because you would be using Red Hat's own 
> distribution) but the effect would be the same.

I've got no philosophical problems with submitting changes to setup.exe to
the maintainers for inclusion in the distributed program. My only interest
in all of this in the first place is to enable users to easily install
Hercules; I'm not, and have no intention of becoming, a Cygwin developer.

> Your remaining problem would be that Cygwin is a "moving target" as you
> say, but Cygwin doesn't move all *that* quickly either, does it? I mean,
> you don't build Hercules against the latest snapshot do you?

Hercules is built against the latest production release of Cygwin at the
time it is released. That version has changed from 1.3.10 to 1.3.19 in the
time between the last two releases of Hercules (2.16.5, released on 8 July
2002, and 2.17, released on 1 February 2003). That counts as a moving
target. In general, Hercules major releases happen every 6 to 9 months.

> Of course, I have no idea how extensively you use the Cygwin API but my
> (arguably little, juding by the size of my projects vs yours) experience
> has always been that if you stick to POSIX compliance, Cygwin does the job
> quite nicely (and patches to Cygwin are usually welcome in case of error,
> provided you have a copyright waiver which I don't have).

Cygwin does the job well enough, or else we wouldn't be having this
discussion. Were it not for inter-version incompatibilities, I'd pick a
version of the DLLs to use, keep one source tarball (and a copy of the email
saying that was sufficient to meet the demands of GPL compliance) around,
and be done with it. Unfortunately, that's not the way it has proven to
work.

> As for GPL rants: I'd be interested (off-list) in hearing your reasons for 
> being against GPL, and even more in what alternatives you would propose.

Sent.

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

Re: Packaging software built with cygwin

[Franz Wolfhagen]

One of the things that your users have been bitten of with the newer
cygwin1.dll is that they impose a stronger authentication mechanism (ntsec
is on per default). This is often brought up here by users that are have
upgraded their version.

Please (re)consider supporting a cygwin package via the cygwin setup - I
can assure you that your application will be much more visible if you are
able to do that (or have somebody to support you doing that) - I  would
love to have a maintained hercules environment on my machine allthough the
license problems for Z/OS in my environment would make me violate the Z/OS
license (now compare that to the GBL ;-)....

If I find the time I will try to install Hercules on my Cygwin environment
which is allways kept on the (b)leeding edge...- - please do not leave us
too soon....

Med venlig hilsen / Regards
Franz Wolfhagen


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

Re: Packaging software built with cygwin

[Joshua Daniel Franklin]

> > The source tarball for cygwin is 4.6M.  I don't understand why this
> > is a huge hardship but, frankly, I don't really care.

> 4.6 MB times how many versions will I need to keep around? Before I removed
> them from the Hercules site, I had four sets of the Cygwin DLLs,
> corresponding to four versions of Hercules they were needed for. Every time
> I release a new version of Hercules, that's another source tarball I'd need.

I realize this is pretty late in the discussion, but I have a suggestion that
might work. Online, you could distribute only the latest, known-working version
of Hercules with cygwin1.dll and the source to that version of cygwin1.dll--no,

you don't need the source to gcc (that's used to build it) nor the source to
TeX (that's used for the documentation) nor the source to Linux (that's also
GPL'd), why would you? 

For older versions, you could put a note stating that due to online space
requirements older cygwin versions are not available online. If you don't have
offline space issues, you could keep an archive around on your personal machine
(or on CD or tape or punch-card or wherever) for emergencies. 
Hopefully in the future some good bug reports can be used to track down
whatever is causing the backward-compaitibility to break, so this would no
longer be necessary. 

Hope this helps and have a nice day.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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