Good time of
day!
We were having some issues with our
makefiles, which are actually caused by our
setup
in Windows ( too long path, too big environment
size).
While investigating this I've looked into
the sources of make v. 3.81 for Windows (built
with the included VS 2003 project )
and found something I couldn't
understand...
1.
process_begin() and find_file() in
w32\subproc\sub_proc.c
Function find_file() uses a
deprecated API OpenFile to find an executable file.
OpenFile has 128
chars limit of file
path.
When the
executable path is longer than 128 chars, find_file either fails to find the file,
or opens it
and returns
success -- but the file name filled in OFSTRUCT is somewhat
unusable.
When later
process_begin() calls CreateProcess, it takes this (bogus) file name from
OFSTRUCT and
crashes.
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.
Now, the single purpose of find_file() is to open the "executable" file and check if it is
a shell script.
But find_file() does not
look for the exact given file
name (without extension) - which can be a shell
script.
Also it does not test
for "known" exts like ".pl", ".sh" and so
on.
Instead it attempts to open and read EXE files... this
IMHO should be fixed.
IMHO something should be done with find_file function:
either fix it using modern win32 APIs (SearchPath etc) instead of
OpenFile,
and recognize "executable" extensions - or remove it
completely as a dead code.
2. The thread body functions have wrong
attribute
In w32\subproc\sub_proc.c; 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 test cases.
If somebody is interested in the changes for w32\subproc\sub_proc.c, as described above, I'll send my mods.
I run with these patches, but have not enough resources and experience for proper testing.
With best regards, keep the good work going
Regards,
Pavel
Aronsky
Engineer
Intel - BWDi
-----Original Message-----
From: Eli Zaretskii [mailto:[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]>
>
> 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?
> From: "Aronsky, Pavel" <[EMAIL PROTECTED]>
>
> 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.
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
[email protected], 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.
problem is specific to the Windows port, send an email message to
[email protected], 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.
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.)
upgrading to it first, perhaps the problem(s) will disappear.)
~~~~~~~~
_______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
