Cygwin stability and releases (was An irritated cygwin newbie)

[Brendan Simon]

"Jon M. Taylor" wrote:

>         Around four hours ago I downloaded the latest "stable" (ha!)
> release, b20.1.  I was a bit nervous about using such an old release, but
> I didn't want to play with snapshots on a project as huge and complex as
> cygwin.  So, I downloaded full.exe and installed it.  I then downloaded
> autoconf, automake and libtool, I figured that, since cygwin comes with
> GNU M4 and /bin/sh all nicely set up, there couldn't be any problems.
> Yeah right.  I had been bitten by the "/bin/sh is ash" bug.  No info about
> this in the FAQ.  After searching the mailing list for every keyword I
> could think of (the list archives at www.cygnus.com are quite broken BTW),
> I finally found out:

It was strongly recommended to me (by Ernie Boyd I think) that follow
upgrades be used.  This might solve some of your stability problems.  There
may be newer ones now.
cygwin-inst-19990115.tar.gz
cygwin1-19990115.dll


> * /bin/sh.exe is actually ash, which is not POSIX-compliant.  The weird
> errors I was seeing when I tried to run .configure were ash improperly
> quoting strings. Copying bash.exe to /bin/sh.exe fixed all my problems.
>
> * This problem has been know about since a few weeks after b20.1 was
> released, which was last December.  Nobody has fixed it, released a new
> cygwin with /bin/sh symlinked to bash.exe, or even updated the FAQ.  ash
> was apparently used 'because it is faster than bash' (direct quote from
> the mailing list).  As if speed could ever be justifiably be a higher
> priority than formal correctness on a system API emulator??....
>
> * b20.1 has been know to be badly broken in a lot of places for quite some
> time now, so much so that people appear to be forced to either stay with
> b19 or use the bleeding-edge snapshots in order to get anything to work
> properly.  Again, this is not mentioned anywhere on sourceware.cygnus.com
> or the FAQ.  Patches and workarounds for the problems with b20.1 are
> piling up, with no release date for a b21 in sight.  People are routinely
> advised to fix their problems with b20.1 by downloading CVS snapshots.
>
>         This is not the way to do things, folks.  If a supposedly-stable
> release goes out the door and a nontrivial bug is discovered (and IMHO the
> sh-is-really-ash thing qualifies), you fix the bugs _first_ before going
> off and starting a bunch of major new changes in CVS, leaving people with
> no choice other than to stick with a quite old release (b19) or be forced
> to use bleeding-edge CVS snapshots.  I find it odd that b20.1 was released
> specifically to fix bugs in b20 (released two months previously), but then
> we get a period of _nine_ months now where many serious bugs with b20.1
> have been reported, and yet there is no b20.2 available and b21 looks like
> being released later rather than sooner.

I agree that it would be nice to have a more up to date stable release.  I
would like to see major releases (eg. b20, b21, b22, etc) scheduled on a
yearly basis and minor releases (b20.1, b20.2, etc) released on a quarterly
basis (in sync with the Sourceware CD).  This is my ideal scenario.  Is this
achievable ?


>         "Beta" implies, if not the formal software-engineering definition
> of "only bug fixes, no new features" (few projects stick to that
> rigorously), at least that bug-fixes and stability in general take
> priority over new features.  That certainly does not appear to be the case
> right now with cygwin, the 'b' on the releases notwithstanding.  I've seen
> many alpha releases from many open-source projects which are far more
> stable than the supposed beta release of b20.  In fact, it is quite
> obvious that the alpha development period of cygwin is far from over.

I haven't had the problems you are describing but I haven't tried to port big
projects using cygwin.  I build cross-compilers and debuggers for the cygwin
runtime environment but I build on linux host with cygwin cross-tools.  This
may make a difference for your build if you try something along these lines.
It is far more likely that you will have success building in a UNIX
environment than the Cygwin environment (at least at this stage).  The ideal
is for both enviornments to be equally successful but that is not the case at
the moment.

Brendan Simon.



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com