Lynn 在 2012-1-14 下午9:49，"Eli Zaretskii" <[email protected]>写道： > > > From: Lynn Lin <[email protected]> > > Date: Sun, 8 Jan 2012 09:27:16 +0800 > > Cc: "[email protected]" <[email protected]> > > > > 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. > Is that fine you send me a patch to me so I can verify it? Thanks very much! > 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 [email protected] https://lists.gnu.org/mailman/listinfo/make-w32
