Mon 12 Jan 2004 11:19:39 AM UTC, original submission:
It appears that make does not search the $(PATH) correctly for commands to be executed (i.e. compilers, tools). If a command can be found in the Windows system directory, for example, it takes precedence over the same command in path. This leads to trouble if the commands differ, e.g. a wrong version of a tool could be easily used by mistake.
Whenever make uses a shell to execute commands, no problems arise. Obviously the shells, including cmd.exe, respect the $(PATH) setting.
Probable sources for the problem are the CreateProcess() and OpenFile() function calls in process_begin() and find_file() functions, respectively, in the w32/subproc/sub_proc.c file.
If these functions are given a file name without directory
path, according to MS Developer Network, the system searches for the file in the directory where the calling application (in this case, make) was found, in the current directory, both Windows system directories and the Windows directory before looking at the PATH environment variable.
Even though this is a feature of these Windows calls, and it might make sense for some applications, it would seem more logical for make to only look at the $(PATH), and nothing else.
This bug was detected using make 3.79.1 mingw32 on Windows 2000. The source references are valid for version 3.80.
---
A short example:
- java.exe can be found in both c:\jdk1.3\bin and c:\winnt\system32
- c:\winnt\system32 is not in PATH
- which looks at PATH only
Makefile:
all:
which java.exe
java -version
Make:
% make -d all
[a lot of garbage removed here and there]
which java.exe
c:\jdk1.3\bin\java.exe
java -version
CreateProcess(C:\WINNT\system32\java.exe,java -version,...)
[etc]
|