On Fri, Jul 9, 2010 at 3:05 PM, Eli Zaretskii <e...@gnu.org> wrote: [snip] >> > Thanks. I used almost all of the patches in w64-all-20100705.diff. >> > >> >> Thanks for applying the patches. >> >> There are some issues, though: > > I forgot to send these upstream, now fixed. >
Thanks. In make.h, the w32_kill prototpe sitll needs updating, though, like: -int w32_kill (int pid, int sig); +int w32_kill (pid_t pid, int sig); ... otherwise build fails. >> * w32/subproc/sub_proc.c: Handles & pids still used with int types >> which really must be intptr_t types as suggested in the patch. See >> these warnings: > > Didn't you need to include stdint.h for these? If not, where did GCC > get the definition of intptr_t? There are many other headers who silently include stdint.h such as process.h. I see that you already included stdint.h in subproc.c, but for completeness' sake, you may want to consider something like: +#ifdef _MSC_VER +#include <stddef.h> +#else #include <stdint.h> +#endif ... because M$VC doesn't have a stdint.h > >> > There's one issue -- with declaration of alloca -- that awaits Paul's >> > response, since I don't think we should include malloc.h. >> > >> >> This one: >> http://lists.gnu.org/archive/html/bug-make/2010-07/msg00054.html >> ... yes? > > Yes, I'm waiting for Paul to respond on this one. > Here are some more nitpicking: * job.c (pid2str): No need for __GNUC__ > 3 because gcc-3.4.5 of mingw.org can handle these, too. Besides, it is ruling out the possibility of M$VC compiler. * job.c (exec_command): Instead of casting the handles to DWORD_PTR, it would be more appropriate casting them to pid_t, ie. changing those two (DWORD_PTR)hWaitPID to (pid_t)hWaitPID ... because pid2str() already accepts pid_t argument. * main.c: You may want to pacify the compiler for the ADD_SIG macro, too, as I did in my suggested patch, something like: #define ADD_SIG(sig) fatal_signal_mask |= sigmask (sig) #else -#define ADD_SIG(sig) (void)sig +#define ADD_SIG(sig) #endif #endif (not much of a problem, but . avoids annoying statement with no effect warnings.) -- Ozkan _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make