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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Peder O. Klingenberg" <peder@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