Function find_file() uses a
deprecated API OpenFile to find an executable file.
OpenFile has limit
of file path 128 chars.
When the
executable path is longer than 128 chars, find_file either can't find the file, or can
open it
and returns
success, but the file name filled in OFSTRUCT is
unusable.
When later
process_begin() calls CreateProcess, it takes the (bogus) file name
from OFSTRUCT - which causes random failures ( errors returned by
CreateProcess or exceptions).
In our environment, we have very long paths so this is a show
stopper.
I am still investigating when exactly either
of these cases happens. There are several cases
when the filename is resolved from %PATH% or
is relative or absolute.
In all cases when we have failures of
CreateProcess, removal of find_file() helps.
2. Detection of
shell script under Windows
In same two
functions as above. Function find_file() does not
look for the given file name without extension - which can be a shell
script.
Instead it attempts to open and read EXE files... this
IMHO should be fixed.
3. The thread
body functions have wrong attribute
Thread body
functions proc_stdin_thread, proc_stdout_thread etc are now used with
_beginthreadex instead of _beginthread.
So they must be explicitly declared __stdcall instead of _cdecl (
default of MSVC ); and typecast in their usages should be removed ( in
process_pipe_io).
However I could not test this fix, these functions were
never called in my tests.
With best wishes, keep the good work
going
Regards,
Pavel
Aronsky
Engineer
Intel - BWDi
-----Original
Message-----
From: Eli Zaretskii [mailto:address@hidden
Sent: Tue, Aug 01,
2006 20:30
To: Aronsky, Pavel
Subject: Re: Do you develop GNU
make?
> Date: Tue, 1 Aug 2006 19:25:55 +0300
>
From: "Aronsky, Pavel" <address@hidden>
>
> We have some issues with the Windows port.
However we are not familiar with GNU procedures of submitting bugs, so we'd
rather find somebody who actively maintains Windows port of gnumake and ask them
to look at these issues.
>
> Are you still developing the make, or
could you suggest somebody else?
I'm helping Paul D. Smith, the official maintainer
of GNU Make, to
maintain the Windows port. I'm doing this on my own
free time (which
is very limited), so no promises.
The procedure of submitting a bug report is very
simple: if the
problem is specific to the Windows port, send an email message
to
address@hidden, state your version
of Make, what commands you issued
and what problems you experienced. It
is best to send the shortest
Makefile that could be used to reproduce the
problem(s). It is also
advisable to describe what compiler and
development environment were
used to build Make, or, if you downloaded a
precompiled binary, where
did you get it.
That's it! There are a few other people who
read the make-w32 mailing
list, so the chance of getting fast and efficient
help is quite high.
(I assume you are using the latest version 3.81 of
Make; if not, try
upgrading to it first, perhaps the problem(s) will
disappear.)
~~~~~~~~
- gnu make 3.81, Windows port,
Aronsky, Pavel <=