delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/01/25/10:14:35

X-Spam-Check-By: sourceware.org
Date: Wed, 25 Jan 2006 10:14:14 -0500 (EST)
From: Igor Peshansky <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: pobox AT verysmall DOT org
cc: cygwin AT cygwin DOT com
Subject: Re: Errors compiling cdrtools under cygwin 1.5.19
In-Reply-To: <43D74ADA.20606@verysmall.org>
Message-ID: <Pine.GSO.4.63.0601251000380.2078@access1.cims.nyu.edu>
References: <012420061825 DOT 2204 DOT 43D671090006A0AD0000089C22092299270A050E040D0C079D0A AT comcast DOT net> <20060124183552 DOT GA2889 AT trixie DOT casa DOT cgf DOT cx> <43D69F82 DOT 8050209 AT verysmall DOT org> <Pine DOT GSO DOT 4 DOT 63 DOT 0601241720270 DOT 3906 AT access1 DOT cims DOT nyu DOT edu> <43D74ADA DOT 20606 AT verysmall DOT org>
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/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

On Wed, 25 Jan 2006, pobox wrote:

> > I like this slogan:  "Cygwin: nice, but not reliable".  We should adopt
> > this, and refer 90% of the mailing list complaints to it. :-)
> > 	Igor
>
> I am not really sure how to understand the joke.

Only that Cygwin cannot be expected to be fully tested and reliable
without input from the users.  People using Cygwin for critical tasks
should either not upgrade, or test the snapshots, so that they are not
caught by surprise at release time.

> cygwin worked flawlessly for me for very long time. May be I have been
> lucky, but this made me develop an attitude of blind trust in cygwin.

Blind trust is always a bad idea.  I'm not aware of any software product
(free or not) that will not change its behavior from time to time.

> Then came this 'getline' problem and what is confusing is not that
> things broke, but the reaction of the cygwin people.

What reaction?  "We have not done anything differently than Linux"?  It's
true.  FWIW, some applications have Cygwin-specific patches in their
codebase that are supposed to work around previous deficiencies in Cygwin.
As Cygwin evolves to be more like Linux, those programs should remove
those kludges.  Some don't.  I'm not saying this is what happened in this
particular case, but that's one possible way in which Cygwin changes can
break another application.

> What I saw is that it is possible that cygwin breaks from one day to the
> next in critical area, and the reaction will be that everything that
> breaks is at its own fault.

An area that is critical for you may not be critical for others.  If it
*is* that critical, why did you not test the snapshots?  There were
multiple calls for this.

Linux has an equivalent getline() call.  Apache (presumably, I haven't
checked) builds on Linux.  Thus, either Cygwin's getline declaration is
somehow different from Linux's (in which case it should be fixed in
Cygwin), or Apache is doing something different in Cygwin than in Linux
(in which case it should be fixed in Apache).  But someone has got to find
out where the fix should go, and the resources of Cygwin developers are
stretched pretty thin as it is.  That someone will have to be the person
for whom building Apache is critical (e.g., you), or a person that
volunteers his time (in which case, you'd have to wait for them to find
enough time to work on this).

Since you mentioned using VMWare, why not install Linux in it and try
building Apache?  Then compare the logs to see what's different in the
builds.

> The problem is that if Apache have not fixed their 'getline' since 2002,
> it is very likely that they will not fix it soon, if at all.

Certainly not if nobody advocates fixing this.  Make some noise -- you
never know, it might have just fallen through the cracks.

> cygwin has quite a marginal place in comparison to all other operating
> systems they should address, an cygwin should be - due to this - a bit
> more careful when challenging the word.

Like any other software, Cygwin has bugs.  These bugs ought to be fixed,
but first they need to be tracked down.  "Apache doesn't build" is not the
bug.  The bug would be "Apache doesn't build because some code that it
expects to be this way is that way".  Reducing it down to a simple test
case (a small program that uses getline() and builds on Linux but not on
Cygwin) would help.  It's also possible, as I said above, that the bug
*is* in Apache, but did not manifest until now.

> At least for me with cygwin is over.

We will gladly refund the full purchase price of this software.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha AT cs DOT nyu DOT edu | igor AT watson DOT ibm DOT com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019