GNU bug report logs - #42095
28.0.50; Build fails on Windows/MinGW64

Previous Next

Full log

Message #29 received at 42095 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnulib <at> gnu.org, peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Mon, 29 Jun 2020 17:13:48 +0300

> Cc: 42095 <at> debbugs.gnu.org, "Peder O. Klingenberg" <peder <at> klingenberg.no>,
>  Gnulib bugs <bug-gnulib <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 28 Jun 2020 13:34:36 -0700
> 
> As I understand it the basic issue here is that we want O_CLOEXEC support even
> on platforms that lack it, and we don't want all the calling software to play
> games with "#ifdef O_CLOEXEC" and the like.

AFAICT, O_CLOEXEC is already supported by the 'open' implementation we
use on MS-Windows ('sys_open' in w32.c), so I think we are good there.

> I attempted to work around this particular problem by installing the attached
> workaround into Gnulib and updating Emacs accordingly. Please give it a try.

Thanks, it builds fine.

> Perhaps this should be fixed more systematically in Gnulib instead of worked
> around, but I suppose that might entail some merging between Emacs's and
> Gnulib's ways of dealing with file names under MS-Windows and I'll leave it to
> the MS-Windows experts to figure out how to do that, or whether they want to do
> it at all.

As long as config.h is included in a Gnulib source file that calls
'open' (and AFAIK all Gnulib files do that), the call will be
redirected to 'sys_open' mentioned above, and everything is supposed
to "just work".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.