Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook?

[Arthur Miller <arthur.miller@live.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: angelo.g0@libero.it,  emacs-devel@gnu.org
>> Date: Tue, 13 Feb 2024 23:05:00 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Arthur Miller <arthur.miller@live.com>
>> >> Cc: emacs-devel@gnu.org, eliz@gnu.org
>> >> Date: Tue, 13 Feb 2024 20:00:16 +0100
>> >> 
>> >> More than the patch, I also had to copy over cp.exe from msys/bin to ucrt64/bin,
>> >> because the cp.exe included in ucrt runtime failed in autogen or configure; I
>> >> don't remember, with message that --force flag is not implemented yet, when some
>> >> script was installing git hooks.
>> >
>> > This seems to indicate that your system is misconfigured: when you run
>> 
>> If they say that cp.exe does not support --force flag, it means it is for some
>> reason incomplete.
>
> I think there's a misunderstanding: you are supposed to use the MSYS
> cp.exe (and grep.exe and gawk.exe and find.exe and some other
> commands) when running the Emacs build process, not the cp.exe
> included with the ucrt runtime.  But the way to make sure you run the
> MSYS executables is to arrange your Emacs-building sessions in a way
> that MSYS programs are on PATH ahead of ucrt and other MinGW programs,
> not by copying MSYS executables into directories where you keep native
> Windows executables.
>
>> Option was to download EZports :)
>
> There's cp.exe in ezwinports.  When I need a native Windows cp.exe, I
> use the one from the old GnuWin32 port.  But when I build Emacs, the
> build runs cp.exe from MSYS, not the native executable.
>
>> > MSYS Bash to build Emacs, the MSYS's bin directory should be on PATH
>> > _ahead_ of the MinGW bin directory, because Bash wants to run MSYS
>> > ports, not MinGW (a.k.a. "native Windows") ports.
>> 
>> Isn't that what their "shell launcher" does for me; sets the correct path(s) for
>> all the forest of stuff they have? This is the path the tool itself sets up;
>> nothing is modified by me; this is what echo $PATH shows:
>> 
>> /ucrt64/bin:/ucrt64/bin/site_perl/5.32.1:/ucrt64/bin/vendor_perl:/ucrt64/bin/core_perl:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/
>
> I wonder what are those ucrt* directories doing there, and what kind
> of executables they hold.  If that's the MSYS stuff, then maybe you
> should take this up with the MSYS2 developers.

Yes, that is the msys stuff, that is how they setup envirnoment from their
shells.  I see GCC & co; the usual stuff (tolchain, base-devel, tex and so
on). Bash is from msys.

https://www.msys2.org/docs/environments/

>> you prefer to keep Emacs as unsuported under ucrt runtime.
>
> I don't mind supporting UCRT, but only if someone volunteers to be the

I would love to help; but I have obviously not enough understanding myself aobut
the problems here, so I can't give adequate help to anyone including myself :);
unfortunately.

> POC and RI for solving any related problems (the one with close_stream
> sounds like a real bug that the patch just sweeps under the carpet --
> not a solution I'd like to have in Emacs).  I myself don't know enough
> about UCRT, don't have the toolchain to build a UCRT Emacs, and
> therefore cannot do that job (even if I forget my other duties here).

The toolchain is just one pacman -S command away, but I understand you about the
time; I would be srpurised if you had :).

I agree that until someone is sure about those close_stream events that crash
the build, it shouldn't be considered as a supported build. I can experiment a
bit more and see if I can find out why they appear; but it can be something in
their environment too.