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

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Mon, 12 Feb 2024 11:06:02 +0100
>> 
>> I am trying to compile Emacs on a new computer with freshly installed 
>> Windows 11
>> and mingw and having some troubles.
>> 
>> ld is complaining about missing snprintf. Seems like I can't get past that
>> one. I am using mingw ucrt toolchain/runtime since m4 failed for "ordinary"
>> mingw-w64 toolchain which I used on Windows 10 (m4 failed creating configure
>> script). Any idea why and what to do? It is defined in stdio.h so I would 
>> expect
>> it to be included in basic libc. Do I need to pass some extra flag
>> compiler/linker flag?
>
> Which problem do you want to solve? the one with creating the
> configure script, so you could use the "ordinary" MinGW toolchain, or
> the one with snprintf?
Seems, like ordinary one works today; but if we can figure out why it does not
link with correct library in ucrt build, it would be nice.

> I don't really understand why you have a problem creating the
> configure script (nor why you think it's m4's fault).  What is
Needer do I; but before I did a git pull today, ./autogen.sh resulted in error
from M4 that some macro was already defined. I don't remember which one. I tried
to trigger it today just to show the error message, but I did a git pull without
thinking before createing a worktree for the build, and autogen suddenly worked.

> different from what you had on Windows 10?  Are you using the same
> development tools copied from the old computer, or did you install
I didn't copy over; that option did cross my mind, but the old one is old since
2016, so I thought it would good to install new stuff a fresh so to say. But
nothing special; just msys2 out of the box, with deps needed to build Emacs.

> them anew?  If the former, there should be no problems with creating
> the configure script.  If all else fails, please show the error
> messages you get trying to create the configure script.
>
> One thing to watch out is to make sure your Git installation doesn't
> perform any EOL conversions.

Yes. I am aware of that one.

> For the snprintf problem, my suggestion is to review the patches the
> MSYS2 folks use for the UCRT build of Emacs.  No one submitted to us
> patches to support UCRT builds, so that build is currently unsupported
> by the upstream project, but AFAIU MSYS2 folks do succeed in building
> it, so I guess they do have patches for it.  It is better to use those
> patches as a starting point.

I didn't know they have one; I'll check it, and come back if I manage to build
it in ucrt runtime.

>> Since I removed msys mingw-w64 from my PATH to be sure mingw-w64-ucrt runtime
>> don't mix with other mingw runtime(s), Git also got removed from the path (I 
>> am
>> using mingw-64 one), and than my running Emacs couldn't open a file from a 
>> Git
>> repo.
>
> The simple fix for that is to have on PATH a git.cmd batch file that
> invokes Git after setting PATH locally (with setlocal) to include the
> directory where you have Git installed.
>
>> The backtrace shows find-file is calling vc-refresh which realized I am in a 
>> Git
>> repo and is trying to call Git. If I start emacs -q afresh without Git in the
>> path, it works fine, so I assume Emacs registers Git program at some point 
>> and
>> does not check for it on every call, perhaps I am wrong about that one?
>
> You don't tell enough to figure out what could be the reason for this.
> What are your customizations doing that could cause Emacs find Git
> even though it is not on PATH?

No no; Emacs does not find it when it is not in the PATH. :)

>> If that would be the case, I think it is a bug to assume that environment 
>> can't
>> change under running Emacs.
>
> Modifying PATH from within a running Emacs session is not recommended,
> precisely because it can cause subtle issues.

It wasn't modified from within Emacs; but from Windows GUI; but the effect is
the same of course.

>> Also, calling vc-refresh obviously results in a quite expensive call to git
>> process everytime I open a file from git repo. Is it really a good default
>> option? At least I interpret it so since emacs -q has vc-refresh in
>> find-file-hook. Why do we even need vc-refresh by default in find-file-hook?
>
> We show the VC status on the mode line.

If that is *the only* reason, can we make that status refresh optional?

It can trigger checks even in files I am not currently working on. For example I
have .emacs.d as a git repo so I can back it up, and I believe I am not the only
one. Save place and recentf for example, and basically every other configuration
that saves something is saving it in .emacs.d. It can be quite many status
checks if it automatically checks git status for all files. There can be other
reasons why I wouldn't like/need those checks in some repos. You can see the
answer to Dmitry for a suggestion.

Thanks for the help.
/a