bug#42095: 28.0.50; Build fails on Windows/MinGW64

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Peder O. Klingenberg
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.




Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
> From: "Peder O. Klingenberg" <[hidden email]>
> 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



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
> Date: Sun, 28 Jun 2020 18:48:42 +0300
> From: Eli Zaretskii <[hidden email]>
> Cc: "Peder O. Klingenberg" <[hidden email]>, [hidden email]
>
> 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?



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Paul Eggert
In reply to this post by Eli Zaretskii
[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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Paul Eggert
In reply to this post by Eli Zaretskii
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.



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Paul Eggert <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Paul Eggert
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.



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
In reply to this post by Paul Eggert
> Cc: [hidden email], "Peder O. Klingenberg" <[hidden email]>,
>  Gnulib bugs <[hidden email]>
> From: Paul Eggert <[hidden email]>
> 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".



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
In reply to this post by Paul Eggert
> Cc: [hidden email], [hidden email]
> From: Paul Eggert <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Paul Eggert
In reply to this post by Eli Zaretskii
On 6/29/20 7:13 AM, Eli Zaretskii wrote:

> Thanks, it builds fine.

Thanks for checking; closing the bug report.



Reply | Threaded
Open this post in threaded view
|

bug#42095: 28.0.50; Build fails on Windows/MinGW64

Eli Zaretskii
In reply to this post by Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Paul Eggert <[hidden email]>
> 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.