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: 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 actually looked in scripts to see what is using -f flag to
cp to rewrite the script but didn't found it. So I had to use another cp
executable. Option was to download EZports :), but it seemed like overkill in
this case.

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

This is what OS sees as the path:

C:\Users\arthu>echo %PATH%
C:\Program Files\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Steel Bank Common Lisp\;C:\Users\arthu\AppData\Local\Microsoft\WindowsApps;C:\Program\emacs-29.2\bin;C:\Program\Java\jdk-21\bin;

I have just added openssh, sbcl and java to the path :).

> Copying MSYS programs into the MinGW bin directory is a bad idea

Yes, I know; I don't do that at all; but I can't imagine that cp.exe is
pulling crap load of libraries behind; it should be quite self-contained, and it
worked.

> will at some point bite you, so my recommendation is not to do so.  In
> general, my advice is to keep MSYS and MinGW executables separate, and
> have separate environments for each one.  In my setup, when I run the
> MSYS Bash, the MSYS executables are found first, but when I run the
> Windows cmd.exe it's the other way around.

I only keep mingw in the system path; no msys at all; but now I removed
everything msys/mingw/ucrt related while I was building Emacs to not pull in
something wrong by a chance. There are three runtime involved, chances some
executable from a wrong runtime gets involved is unfortunately not so small.

>> Emacs seems to work as usual thus far, but the native compiler complains about
>> missing function:
>> 
>> Debugger entered--Lisp error: (void-function comp-write-bytecode-file)
>>   comp-write-bytecode-file("c:/Users/arthu/.emacs.d/eln-cache/30.0.50-ccd5287a/dired-auto-readme-d510bed9-ac3fa899.eln")
>>   emacs-lisp-native-compile()
>>   emacs-lisp-native-compile-and-load()
>>   funcall-interactively(emacs-lisp-native-compile-and-load)
>>   command-execute(emacs-lisp-native-compile-and-load)
>
> This should be fixed now on the master branch.
>
>> I also did got the message that Emacs is not functional at the end of the build:
>> 
>>   GEN      ../../info/efaq-w32.info
>> org.texi:15658: warning: @anchor should not appear on @item line
>> org.texi:15671: warning: @anchor should not appear on @item line
>
> This is a harmless warning, so it shouldn't stop the build.

I though so; but I wasn't sure. I am a bit suspicious about discarding those
close_stream errors ad they do in the patch, but thus far it seems to work.

>> make[2]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64/doc/misc'
>> make[1]: Leaving directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
>> make sanity-check make-target=all
>> make[1]: Entering directory '/c/Users/arthu/repos/emsrc/ucrt-w64'
>> ***
>> *** "make all" succeeded, but Emacs is not functional.
>
> Maybe it's because of the problem with comp-write-bytecode-file.

Could be.

Anyway, that was what I needed to build it on ucrt runtime with GCC. Guys at
msys are pointing out that their repo is bsd3 license and gpl compatible and
thus free for all, so they are not sending in any patches. It is anyway just 3
ifdefs; less than 10 lines of code, so decide yourself if you are going to patch it
in and test further or you prefer to keep Emacs as unsuported under ucrt runtime.

Thanks for looking through this.
/a