----- Original Message -----
From: Dennis Bjorklund <db@...>
Date: Saturday, March 2, 2002 10:55 pm
Subject: Re: [Mingw-users] make
> On Sat, 2 Mar 2002, Paul Garceau wrote:
> > Known problem with make.exe. Since you are referencing MSYS here,
> > you might want to substitued gmake.exe for make.exe. Problem with
> > make.exe has to do with the inability of the utility to properly
> > convert from "->" or visa-versa on Win32 platforms.
> I'm sorry to continue this thread, but I don't understand. Why is
> there a
> conversion of "->" from and to what? Are we talking about the
> string "->"
> or is this something else? I've used make many years and I've
> never ever
> seen "->" as anything special, and I don't see "->" in my test case.
Forgive any confusion...let me restate...
there is a problem with make.exe. It is known that make.exe has
problems differentiating between the character ', and the character ".
This applies in win32 environments, not in Unix environments.
Win32 environments get confused when they see the quote (") mark and
assume it is a path delimiter. Character quote (") is used by Win32 OS
to quantify path references; ie. when you type at your command console
something like the following:
d:\my prog\my dir\executable
Win32 (9x, NT4, Win2k, XP) always sees it this way:
"d:\my prog\my dir\executable"
If you use the singleton version of quote (') mark in a Win32 path
reference; ie. When you type in your makefile something like the
echo 'd:\my prog\my dir\executable'
Win32 based OS always pads it with standard quotes (").
"'d:\my prog\my dir\executable'"
make.exe is not smart enough to strip out the singleton quote (').
So, when you go to generate the process (Make Create Process())
this is what comes out:
createprocess() using executable defined as "'d:\my prog\my
dir\executable'", fails. It fails because there is no such thing as
'd:\my prog\my dir\executable'.
> I think make does call CreateProcess with the correct parameters,
> then how
> can the problem be in make?
Yes, it does (make does call CreateProcess with correct parameters,
as far as CreateProcess() is concerned). The CreateProcess does what it
is supposed to do. It is the OS interface that is at the heart of this
> In this case it calls CreateProcess with
> "Y:\msys\1.0\bin\echo.exe" as the program and with the command
> line as
> 'echo test=\"Y:/msys/1.0/mingw/bin/make.exe/\"'. That is, the "
> have been
here is where the confusion lies:
command line = "echo test=\"Y:/msys/1.0/mingw/bin/make.exe/\" is
translated by Win32 to the following:
after parsing using above padding, etc. you get this (approximate
where <null>=0x00. 0x00 is what make.exe uses to separate character
data fields (if make.exe is built with gcc) and is most closely
associated with the /n or "newline" character (0x00).
after parsing we get the following processes trying to be generated
(not fault of CreateProcess since CreateProcess attempts to stack
various "commands" whenever it can, that is how CreateProcess works)
p2$=<null> or 0x00
Here is what CreateProcess attempts to do:
CreateProcess(echo test=) [note standard quotes are stripped]
CreateProcess(Y:/msys/1.0/mingw/bin/make.exe) [note backslash is
Of course, you won't ever get to the second CreateProcess call, even
though it is completely legal, because the first CreateProcess call is
invalid/illegal (according to Win32) and not because of the
CreateProcess function. There is no such thing as "./echo test=.exe/n"
(binary representation) or "echo test=.exe" (string representation).
"Error: CreateProcess(xxx) failed. Aborting Make".
> Maybe one can change make so it uses /usr/mingw/bin/make or
> /y/msys/1.0/mingw/bin/make.exe for the variable MAKE instead of
> the msdos-name Y:\msys\1.0\mingw\bin\make.exe. If that makes a
> I don't know since I don't understand your explanation yet.
Hopefully the above is less confusing. Afaik, changing path format
doesn't matter. It is how make.exe handles specific strings [such as
those necessary before CreateProcess() is actually called by make.exe].
That is why for msys I recommended that you use gmake.exe instead of
make.exe. gmake handles parsing better.
Hope this helps.