Mail Archives: cygwin/2001/10/09/02:59:26
----- Original Message -----
From: "John Peacock" <jpeacock AT rowman DOT com>
To: <cygwin AT cygwin DOT com>
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/
- Raw text -