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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42095 in the body.
You can then email your comments to 42095 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Build fails on Windows/MinGW64
Date: Sat, 27 Jun 2020 23:28:17 +0200

I wanted to refresh my Windows Emacs build tonight, for the first time
in some months.  I pulled up to
5ce5cf643840cd6efd25d987bc5b6f12478c50a6 by Paul Eggert and ran make -j4
as usual.  The build failed.  Likewise make bootstrap.  The error:

  CC       open.o
open.c: In function 'sys_open':
open.c:127:48: error: 'O_CLOEXEC' undeclared (first use in this function)
  127 |                   flags & ~(have_cloexec < 0 ? O_CLOEXEC : 0), mode);
      |                                                ^~~~~~~~~
open.c:127:48: note: each undeclared identifier is reported only once for each function it appears in

That line was changed a few hours ago, in commit
118c07e02e939c9f52688091509d4bff2a897032, also by Paul.

Checking out the commit prior to 118c07 seems to get past the error.
The line and its surroundings look fairly similar in that revision
(ffb89e), so I'm not sure what would be the proper fix.  Hence no
patch, sorry.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Message #8 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: "Peder O. Klingenberg" <peder <at> klingenberg.no>, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Sun, 28 Jun 2020 18:48:42 +0300

> From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
> Date: Sat, 27 Jun 2020 23:28:17 +0200
> 
> I wanted to refresh my Windows Emacs build tonight, for the first time
> in some months.  I pulled up to
> 5ce5cf643840cd6efd25d987bc5b6f12478c50a6 by Paul Eggert and ran make -j4
> as usual.  The build failed.  Likewise make bootstrap.  The error:
> 
>   CC       open.o
> open.c: In function 'sys_open':
> open.c:127:48: error: 'O_CLOEXEC' undeclared (first use in this function)
>   127 |                   flags & ~(have_cloexec < 0 ? O_CLOEXEC : 0), mode);
>       |                                                ^~~~~~~~~
> open.c:127:48: note: each undeclared identifier is reported only once for each function it appears in
> 
> That line was changed a few hours ago, in commit
> 118c07e02e939c9f52688091509d4bff2a897032, also by Paul.

Thanks for reporting this.  lib/open.c should not be compiled in the
MinGW build.

Paul, this problem should be solved in Gnulib, because its open.m4
unconditionally forces lib/open.c to be compiled in the MinGW build:

  case "$host_os" in
    mingw* | pw*)
      REPLACE_OPEN=1
      ;;

The latest changes made this code run even in the MinGW build, not
sure why (perhaps because 'getrandom' uses 'open'?).  Emacs cannot use
Gnulib's 'open' (or any other function that takes file names and
operates on files), because Gnulib on Windows doesn't support UTF-8
encoded file names, which Emacs needs.  We have our own replacements
for 'open' and its ilk.  That is why nt/gnulib-cfg.mk says

  OMIT_GNULIB_MODULE_open = true

But this is no longer enough, since these latest changes.

Please provide a way to reliably avoid compiling lib/open.c on
Windows.  I needed to hack configure to make it build here.

Thanks.

P.S.  The 'getrandom' module had other MinGW-related problems, some of
which I fixed in master, and others were reported to the Gnulib
mailing list:

  https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00059.html

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Sun, 28 Jun 2020 22:36:12 +0300

> Date: Sun, 28 Jun 2020 18:48:42 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: "Peder O. Klingenberg" <peder <at> klingenberg.no>, 42095 <at> debbugs.gnu.org
> 
> P.S.  The 'getrandom' module had other MinGW-related problems, some of
> which I fixed in master, and others were reported to the Gnulib
> mailing list:
> 
>   https://lists.gnu.org/archive/html/bug-gnulib/2020-06/msg00059.html

Btw, do we have any tests in our test suite to test the getrandom
function?  I only found gnutls-tests, but they only seem to call this
for new enough version of GnuTLS.  Is it possible to come up with a
few tests?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 "Peder O. Klingenberg" <peder <at> klingenberg.no>, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Sun, 28 Jun 2020 13:34:36 -0700

[Message part 1 (text/plain, inline)]

[ccing bug-gnulib; this is about <https://bugs.gnu.org/42095>.]

> The latest changes made this code run even in the MinGW build, not
> sure why (perhaps because 'getrandom' uses 'open'?).

That's part of it. It's also needed for recent changes to the getloadavg module.
And I see that the at-internal module also depends on the 'open' module, I
presume because lib/openat-proc.c opens /proc/self/fd/NNN/, but this surely
won't work in mingw.

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.

I attempted to work around this particular problem by installing the attached
workaround into Gnulib and updating Emacs accordingly. Please give it a try.
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.

[0001-getrandom-do-not-depend-on-open-on-mingw.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Sun, 28 Jun 2020 13:35:41 -0700

On 6/28/20 12:36 PM, Eli Zaretskii wrote:
> do we have any tests in our test suite to test the getrandom
> function?

No. Contributions would be welcome, I assume. Testing randomness is nontrivial,
though.

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

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eli Zaretskii <eliz <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 00:20:24 +0200

> > do we have any tests in our test suite to test the getrandom
> > function?
>
> No. Contributions would be welcome, I assume. Testing randomness is nontrivial,
> though.

Maybe Emacs has no unit test for getrandom(), but gnulib has:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-getrandom.c;h=0e9fbb0c26b9f54087be4cf7371b0488dba59f4e;hb=HEAD

It does not really check randomness. It only verifies that different calls
produce different results.

If someone wants to provide such tests, I recall that Knuth's TAOCP II
contains the mathematical foundations of such analysis.

Bruno

Message #23 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: 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 05:28:52 +0300

> Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 28 Jun 2020 13:35:41 -0700
> 
> On 6/28/20 12:36 PM, Eli Zaretskii wrote:
> > do we have any tests in our test suite to test the getrandom
> > function?
> 
> No. Contributions would be welcome, I assume. Testing randomness is nontrivial,
> though.

I just wanted something to cause the call to getrandom, just to see it
working and producing some reasonable value.  Would that be easy to
arrange?

Thanks.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
Subject: Re: bug#42095: 28.0.50; Build fails on Windows/MinGW64
Date: Sun, 28 Jun 2020 23:56:44 -0700

On 6/28/20 7:28 PM, Eli Zaretskii wrote:
> I just wanted something to cause the call to getrandom, just to see it
> working and producing some reasonable value.  Would that be easy to
> arrange?

If all we want to do is call getrandom, the Gnulib module 'getrandom-tests' does
that.

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".

Message #32 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: 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:52:34 +0300

> Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 28 Jun 2020 23:56:44 -0700
> 
> On 6/28/20 7:28 PM, Eli Zaretskii wrote:
> > I just wanted something to cause the call to getrandom, just to see it
> > working and producing some reasonable value.  Would that be easy to
> > arrange?
> 
> If all we want to do is call getrandom, the Gnulib module 'getrandom-tests' does
> that.

I meant to make sure it works when invoked from Emacs.  Sorry for not
making that clear.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 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 09:56:42 -0700

[Message part 1 (text/plain, inline)]

On 6/29/20 7:52 AM, Eli Zaretskii wrote:
> I meant to make sure it works when invoked from Emacs.

I added the attached.

[0001-test-src-fns-tests.el-test-secure-hash-Test-getrando.patch (text/x-patch, attachment)]

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

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

On 6/29/20 7:13 AM, Eli Zaretskii wrote:

> Thanks, it builds fine.

Thanks for checking; closing the bug report.

Message #43 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: 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 21:45:41 +0300

> Cc: peder <at> klingenberg.no, 42095 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 29 Jun 2020 09:56:42 -0700
> 
> > I meant to make sure it works when invoked from Emacs.
> 
> I added the attached.

Thanks, the test passes on MS-Windows.

Previous Next

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