Hello Marat, On Sat, May 03, 2014 at 11:00:51AM +0400, Marat Radchenko wrote: > On Wed, Apr 30, 2014 at 01:41:25PM +0200, Stepan Kasal wrote: > > On Tue, Apr 29, 2014 at 01:12:04PM +0400, Marat Radchenko wrote: > > > On MinGW-W64, MsgWaitForMultipleObjects is guarded with #ifndef NOGDI. > > > > > > Removal -DNOGDI=1 from config.mak.uname has an undesirable effect of [..] > > > > compat/poll/poll.c comes from Gnulib, so it would be better to submit [..] > > That's why v1 of this patch [1] didn't touch poll.c at all. ouch! It looks like you everyone sending you elsewhere. I apologize for being part of that. (I was not aware about the previous version.) > I don't think it's gnulib problem that combination of two third-parties > (git and mingw-w64) set up such conditions where poll.c fails to compile. Well, yes and no: gnulib is mostly a collection of compatibility reimplementaions of functions that should be available on an ideal system. > If one wants to dig deeper, I'd say the problem is in MinGW-W64 headers > because their behavior of hiding MsgWaitForMultipleObjects doesn't > match behavior of MSVC headers. Thank you very much for this analysis. It enables us to redirect you the third time: to report this as a bug in MinGW-W64 ! ;-) Seriously, it looks you found the best description of the problem, and it would be nice if you could modify your patch so that it is really a work around: it would be in effect only for MinGW-W64, and the comment would explain that this is a hack to work around the bug. If you manage to change the defs for poll.c without changing its content, no one could tell you to report to gnulib first. OTOH, if MsgWaitForMultipleObjects is present ustream (in gnulib's poll.c, sorry that I cannot check right now), it still might be better to submit the work-around there first. Thanks for your work, Stepan Kasal -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html