From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: cygwin32 (mingw32) news update
1 Dec 1997 16:41:26 -0800
Message-ID: <9712011702.AA18011.cygnus.gnu-win32@modi.xraylith.wisc.edu>
References: <199712010401 DOT EAA43478 AT out1 DOT ibm DOT net>
To: vischne AT ibm DOT net
Cc: gnu-win32 AT cygnus DOT com

vischne AT ibm DOT net writes:
> 
> Only one or two problems:
> 
> mingw32 make emphatically does not work.  It needs sh.exe, and, when it
> gets cygwin sh.exe, it has directory addressing conflicts.  It definitely
> does not understand GNU makefiles, even when individual command-line
> compiles work.

Yeah, this is certainly a problem. I'll check with the other make port
(which I should've known about ;-) to see if it fixes the problem. btw,
mingw32 make *does not* need sh.exe; it uses sh.exe if it finds in the
path. Of course, if there is no sh.exe in path, then sh specific commands
will fail (eg., 'cd blah; $(MAKE) all').

To make things worse, Cygwin32 bash seems to have a problem with the 
following construct:

    sh -c "c:/path/to/executable.exe args"

Where the pathname is not converted to //c/path/to/executable.exe.

my make port has another bug which might be due to the "quote eating"
habit of MS CRTDLL spawn functions. This is a low priority for me, but
I'll of course accept patches from you to fix this behaviour.

> 
> For some odd reason, compiling a program or library that references sleep,
> _sleep, __sleep, or Sleep fails during link, no matter what `extra'
> libraries are referenced.
> 

It does not fail for me. I've asked you for more information, and I'd
appreciate a response.

Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".