From: Stepan Kasal <kasal@ucw.cz>
To: Marat Radchenko <marat@slonopotamus.org>
Cc: GIT Mailing-list <git@vger.kernel.org>,
Felipe Contreras <felipe.contreras@gmail.com>,
Erik Faye-Lund <kusmabite@gmail.com>,
msysGit <msysgit@googlegroups.com>
Subject: Re: [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI
Date: Sun, 4 May 2014 20:52:44 +0200 [thread overview]
Message-ID: <20140504185244.GA17183@camelia.ucw.cz> (raw)
In-Reply-To: <20140503070050.GA8580@seldon>
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
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2014-05-04 18:52 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 9:11 [PATCH v2] MinGW(-W64) cross-compilation Marat Radchenko
2014-04-29 9:11 ` [PATCH 01/12] MINGW: compat/mingw.h: do not attempt to redefine lseek on mingw-w64 Marat Radchenko
2014-04-29 9:11 ` [PATCH 02/12] MSVC: config.mak.uname: drop -D__USE_MINGW_ACCESS from CFLAGS Marat Radchenko
2014-04-29 9:11 ` [PATCH 03/12] MINGW: compat/mingw.h: drop fork() definition Marat Radchenko
2014-04-29 9:11 ` [PATCH 04/12] MINGW: do not fail at redefining pid_t on MinGW-W64 Marat Radchenko
2014-04-29 9:11 ` [PATCH 05/12] MINGW: config.mak.uname: allow using cURL for non-msysGit builds Marat Radchenko
2014-04-29 9:12 ` [PATCH 06/12] MINGW: git-compat-util.h: use inttypes.h for printf macros Marat Radchenko
2014-04-29 9:12 ` [PATCH 07/12] MINGW: config.mak.uname: reorganize MINGW settings Marat Radchenko
2014-04-29 9:12 ` [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c Marat Radchenko
2014-04-30 8:35 ` Karsten Blees
2014-04-30 8:56 ` Erik Faye-Lund
2014-04-30 12:31 ` Johannes Schindelin
2014-04-30 16:38 ` Felipe Contreras
2014-04-30 22:17 ` Stepan Kasal
2014-04-30 22:28 ` [PATCH] Win32: move main macro to a function Stepan Kasal
2014-05-03 7:43 ` [PATCH 08/12] MINGW: fix main() signature in http-fetch.c and remote-curl.c Marat Radchenko
2014-04-29 9:12 ` [PATCH 09/12] Makefile: introduce CROSS_COMPILE variable Marat Radchenko
2014-04-29 9:12 ` [PATCH 10/12] MINGW: compat/poll/poll.c: undef NOGDI Marat Radchenko
2014-04-30 11:41 ` Stepan Kasal
2014-05-03 7:00 ` Marat Radchenko
2014-05-04 18:52 ` Stepan Kasal [this message]
2014-05-04 20:55 ` Marat Radchenko
2014-05-04 21:46 ` '502304919' via msysGit
2014-05-05 7:35 ` Stepan Kasal
2014-05-05 7:32 ` Felipe Contreras
2014-05-05 12:15 ` [msysGit] " Stepan Kasal
2014-05-04 20:14 ` Felipe Contreras
2014-04-29 9:12 ` [PATCH 11/12] compat/nedmalloc/malloc.c.h: fix compilation under MinGW-W64 Marat Radchenko
2014-04-29 9:12 ` [PATCH 12/12] MINGW: config.mak.uname: add explicit way to request MinGW-build Marat Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140504185244.GA17183@camelia.ucw.cz \
--to=kasal@ucw.cz \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=kusmabite@gmail.com \
--cc=marat@slonopotamus.org \
--cc=msysgit@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).