bug#72335: An attempt to fix UCRT64 build failure

[Eli Zaretskii <eliz@gnu.org>]

tags 72335 wontfix
thanks

> Date: Sun, 28 Jul 2024 22:55:48 +0900
> From:  "YI Yue" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> I occasionally try to compile Emacs to get the latest commits. But on Windows, I
> only use Mingw64 because it's the only one officially supported by Emacs.[1]
> When I try to build Emacs in MSYS2/UCRT64, I'll get these outputs:
> 
> ./temacs --batch  -l loadup --temacs=pbootstrap \
>         --bin-dest '/d/user/yy/emacs-build/bin/' --eln-dest '/d/user/yy/emacs-build/lib/emacs/31.0.50/'
> D:\user\yy\emacs-master\src\temacs.exe: Write error to standard output: No such file or directory

The UCRT build of Emacs on MS-Windows is not officially supported.
And it will remain unsupported until some volunteer steps forward to
take the responsibility for testing, maintaining, and developing Emacs
on Windows when linked with UCRT.  I asked several times for such a
volunteer, but no one picked up the gauntlet.

The first job of such a volunteer, if and when he or she steps up,
will be to solve this and a couple of other problems which were
reported lately for this build.  Until now, the attempts to understand
why close_stream fails for the standard streams in the UCRT build were
unsuccessful, unfortunately, even though these attempts included the
study of the UCRT sources that are available on the Internet.

> MSYS2 do provides a patch[2] that do something about function
> `close_output_streams' in src/sysdep.c. By applying it, I can get these results:
> 
> ***
> *** "make all" succeeded, but Emacs is not functional.
> ***

Those patches are ad-hoc and come without a satisfactory explanation
of their reason(s).  Being able to make sure the standard streams are
successfully closed is important, so I don't want to disable that in
the upstream sources.  Emacs is Free Software, so people can always
apply those patches to their local builds if they must use the UCRT
build and if they don't care about stdout/stderr.

> Sometimes I'll check emacs-devel to see if there are any progress in solving
> this problem, such as this[3]. Two days ago I saw Pip Cet's "MPS: Win64
> testers?"[4] and it inspired me that the problem may come from `init_ntproc' in
> src/w32.c. After seeing UCRT's documentation[5], I think maybe we can use
> `_fcloseall' instead of `fclose'? By using this, I get no error above when building 
> in MSYS2/UCRT64.

I don't think _fcloseall is what we need: according to the MS
documentation, it closes all the streams _except_ the standard ones,
so it's the exact opposite of what we need.