Re: MinGW build on master fails with Error 127

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 18:57:55 +0100
> 
> MSYS2 distributes multiple toolset/c-runtime combinations. Toolsets can
> be GNU (gcc, binutils, etc) or Clang, and c-runtime can be either
> mingw-w64 or UCRT. For a given combination the toolset is configured to
> work with a c-runtime, so it already knows what it needs to do the right
> thing. I guess it is possible to override the configuration of a toolset
> so to use a different c-runtime, but that's not something that MSYS2
> encourage.
> 
> > And what can users do to force MinGW64 to link against MSVCRT, if they
> > so wish?
> 
> The MSYS2 distribution named "MINGW64" already links to MSVCRT, as
> always did, and that will not change. Is the UCRT64 distribution the one
> that provides a gcc/binutils/everything-else that links to UCRT.

So if the user has the UCRT version installed, they will necessarily
link against UCRT64.

Does the wording in nt/INSTALL.W64 guide users to only one of these
two variants (and if so, to which one), or is it generic, and the user
will have to choose when they install MinGW?

> >> There is a patch specific for UCRT support. It's quite simple although
> >> the workaround for close_stream doesn't inspire confidence, hints that
> >> there might be subtle differences on the behavior of C runtime
> >> functions.
> >
> > It's a beginning of a very long journey, to learn about UCRT what
> > we've invested decades to learn about MSVCRT.
> 
> AFAIK UCRT should work just fine (TM) as it is not an entirely new C
> Runtime, but a vastly updated version of MSVCRT with a new model of
> deployment for more robust versioning that allows incremental additions.
> I'm sure there are subtle differences and even some intended departure
> from behaviors that are deemed undesirable, though.

Subtle differences do exist, as that patch demonstrates.

Whether it will be painless for Emacs depends on how much of the
sources of MSVCRT was inherited by UCRT.  There are some quirks in
MSVCRT that took us time to find out and accommodate for, and w32.c
mentions that in several places.

> My experience, both with my own projects and with the packages MSYS2
> distributes, indicate that migrating to it is fairly painless, if
> noticeable at all.

See above: Emacs is quite demanding in this regard, so I'm not as
optimistic as you are, having spent enough hours reading the MSVCRT
sources and documentation.

> > And the patch indeed is not really acceptable, as it disables useful
> > behavior without a reasonable explanation.
> 
> The commit message says "fclose fail during atexit as if they were
> already closed" but indeed it doesn't describe a user-visible problem. I
> can ask for more details, if you are interested.

I am.  And note that the MS documentation shows an example where an
atexit function calls printf, so the standard streams are not really
closed at that time.  Something else is at work here, probably.

> > Are the sources of UCRT available somewhere (as MSVCRT sources were)?
> 
> They are distributed with Visual Studio. They are missing from a
> Community (the gratis version) install that I have around, but maybe I
> didn't check the option for installing them.

IME, being able to examine the sources was invaluable in quickly
resolving some issues.