> From: Lynn Lin <lynn.xin....@gmail.com> > Date: Sun, 8 Jan 2012 09:27:16 +0800 > Cc: "help-m...@gnu.org" <help-m...@gnu.org> > > Thanks very much for your quick response. > > I am not sure whether I describe this issue well. The third party call the > perl script (this perl script call gmake) perl use pipe to capture gmake > output .It report the above error > > There is one piece code in makefile. > DDIRS = $( foreach dir,$(OBJLISTDIR),$(shell cmd.exe /C "md $(dir) 1>NUL > 2>NUL))) > > %.bin:... $(DDIRS) > command > > If I remove 1>NUL and 2>NUL ,the error go away. But I continue see the error > which haven't identified in which makefile code > > Process_easy : DuplicateHandle(In) failed (e=6) > processor_easy: failed to launch process failed (e=6)
I moved this discussion here from help-make, as this problem is specific to the Windows port of GNU Make. This problem was intermittently reported for the past several years. It was not solved because no simple reproducible test case was ever presented which I could use to debug the problem and verify a possible solution. Now I've succeeded to craft such a test case, which shows at least one situation where DuplicateHandle fails when Make attempts to launch a subsidiary program. But I need help from people who know more than I do about standard handles in Windows programs. The situation is very simple: sometimes Make is invoked from other Windows programs so that GetStdHandle returns NULL for one or more of the 3 standard handles. The current code in Make blithely passes that NULL to DuplicateHandle, which predictably fails, causing the above error message. The question is what to do instead of calling DuplicateHandle with NULL. One possibility would be to pass that NULL to the subsidiary application we invoke via CreateProcess, by leaving the corresponding slot in pproc->sv_* array at its initial NULL value (see process_easy and process_init_fd in sub_proc.c). Could that be a problem on the subsidiary process's end? If this won't do any harm, this is the easiest way out. Another possibility is to connect the NULL handles to the null device. Yet another possibility is to create a console and redirect these handles to that console. But I think this is too gross, and also will probably not DTRT, as the application that invoked Make really didn't mean it to input or output anything. Any suggestions and ideas are welcome. TIA _______________________________________________ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32