Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > And as long as I have your attention: what about the switch to UCRT64?
>> > Does Emacs need something in its Makefile's to specify linking against
>> > MSVCRT, even though UCRT64 is the default?  The information at
>> >
>> >   
>> > https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64
>> >
>> > doesn't provide any details about that.
>> 
>> See
>> 
>> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs
>
> There's nothing there regarding the runtime against which Emacs is
> being linked.  How does GCC/ld know which runtime to link against?  Up
> until now GCC would call the linker with the -lmsvcrt switch, so does
> it now use some other switch?

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.

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

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.

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

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