Mail Archives: cygwin/2001/06/27/03:55:11
> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Tuesday, June 26, 2001 10:14 PM
> To: cygwin AT cygwin DOT com
> Subject: Re: Patch: Bug: Shell fork/exec avoidance in make-3.79.1-3
>
>
> On Tue, Jun 26, 2001 at 08:56:50PM +0200, Bernard Dautrevaux wrote:
> >> I've included a patch below that changes all the char[] definitions
> >> in job.c to char*.
> >
> >I don't think that is the problem; if I look at your patch
> below, the char[]
> >definitions you change in char* are only used on AMIGA or
> VMS, but *NOT* on
> >CYGWIN... ;-(
>
> Sorry, no. The original poster obviously did some research
> here. There
> is a definite problem between 'char *' and 'char []' in the
> default_shell definition.
Sorry for the confusion; it appears I was using the source for
make-3.79.1-2, not -3, and in -2 the ifdefs in job.c were a bit different,
so that the first ifdef read:
#ifdef WIN32_OR_CYGWIN
and thus all was working OK... It was partly my fault (and partly due to
working a bit late yesterday evening), partly due to an obvious regression
in -3 compared to -2. In fact I was even once more puzzled how well broken
code can work: I would have expected a more brutal error (like a DrWatson
popup) for a variable being used in one part of the code as a pointer and in
another as an array of chars.
In fact the code in -2 was correct as the "char*" definition in main.c was
only present on CYGWIN and MSDOS, two cases where it was correctly defined
as char* in job.c. But of course, defining ALL default_shell as "char*" is
The Right Thing (TM).
>
> >If you look at my previous message (posted about in paralell
> with your),
> >you'll see that just recompiling the code without any change
> allow me to get
> >a working make. I suspect your change (that does nothing on
> CYGWIN) is just
> >exercising the same behaviour. IMHO it's just the cygwin
> package that was
> >compiled in a buggy environment.
>
> I build make on linux, like all of my packages. To the best
> of my knowledge,
> I have never had a corrupted environment. I build everything
> in a standard
> way using standard scripts. If I detect an error, I correct
> the script.
I can understand this; in fact I'm working exactly in the same way (although
for mingw32) and was only compiling natively under cygwin for the first time
since several years for these tests yesterday.
>
> >IIRC it happens some time ago to Corinna to have a
> screwed-up environment
> >that generated a working bash that shows a bug that disapear
> after she
> >updates its environment. I suspect the make maintainer have
> (or had) the
> >same problem...
>
> I suspect that your suspicion is wrong.
Sure it it :-) Anyway, if I had noticed that you were the cygwin make
maintainer I would have not suspected this but better looked at MY
environment (that in fact WAS a bit broken because I was using a version
that was too old to show the bug...).
In fact that shows a small problem with the 'patch' level of tools: there is
no way when you look at the source code or at the executable to know which
patch level you are using: both say 3.79.1, with no patch level ;-( With the
installed tool, you can look in the update.db file, but for the source...
Anyway as this is corrected, all is fine and I must congrat all those that
find the problem.
Bernard
>
> 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/
>
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux AT microprocess DOT com
b DOT dautrevaux AT usa DOT net
--------------------------------------------
--
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 -