Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <005501c15090$30366b30$0200a8c0@lifelesswks> From: "Robert Collins" To: "John Peacock" , References: <3BC1CF2E DOT 7177 DOT 33050F17 AT localhost> <3BC1B8C0 DOT C1E58D08 AT rowman DOT com> <20011008115635 DOT A18826 AT redhat DOT com> <3BC1D323 DOT 861B6670 AT rowman DOT com> <20011008150120 DOT A19660 AT redhat DOT com> <3BC1FF9D DOT 6BA1CEB AT rowman DOT com> Subject: Re: Perl 5.7.2 Date: Tue, 9 Oct 2001 17:01:12 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 09 Oct 2001 07:07:24.0443 (UTC) FILETIME=[0BF8F6B0:01C15091] ----- Original Message ----- From: "John Peacock" To: Sent: Tuesday, October 09, 2001 5:33 AM Subject: Re: Perl 5.7.2 > Christopher Faylor wrote: > > > > I saw your original message which actually did provide a surprising > > amount of detail but I really don't have the time to load bleadperl > > (whatever that might be) onto my system in an attempt to try to > > duplicate your problem. So, I guess this is a pretty classic stalemate. > > Now that I have calmed down, I am still willing to keep banging and > trying to work this through. I'll grab the latest snapshot and see > what that does. I am more focused on fixing Perl, but if I have to fix > CygWin to do it, so be it. I think this point is worth examining: When is it appropriate to 'fix' the source for a cygwin-linked binary, and when is it appropriate to 'fix' the source for cygwin? Well, IMO if and only if the fault is specific to cygwin, and not related to (CR/LF || dos-path-integration || running-as-a-daemon/service || assuming things about the platform (ie which headers exist || backlinking is supported)) then _cygwin_ needs to be patched. If the fault occurs on other unix-api systems, or relates to dealing with (CR/LF || dos-path-integration || running as a daemon || assuming things about the platform (ie which headers exist)) then 99% of the time the application sources needs altering. By this, I mean to point out that if the development branch of perl is having trouble with cygwin, and the changes aren't in the categories I've listed above then you should be debugging cygwin-with-perl-with reference to a linux machine to decide if the fault is cygwin or perl. Or in short, to make useful progress debugging the development branch of a unix-originated piece of software you really need: 1) a unix box. (emulated a la vmware will do) 2) a win32 machine with cygwin CVS built with debugging. 3) the software you want to debug, on both 1) and 2), first eliminate all common bugs, then the remainder are cygwin related. Filter the conditions I listed above on the remaining bugs and you will have two lists: a) fix-in-your code bugs b) _potential_ cygwin bugs You probably know this already, but I thought it was worth mentioning. In the porting I've done, I've found that 80%-90% of the cannot-compile-and-link bugs are platform assumptions that are incorrect for cygwin. OTOH, I've found about 80%-90% of the compiles and links but crashes bugs are cygwin related - given that the bug does not occur on other platforms. So for me, when something crashes just on cygwin, the first thing I do is grab my debug build of cygwin1.dll. Rob -- 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/