Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii <eliz@gnu.org>]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 23 Feb 2024 08:58:43 +0100
> 
> >> +#ifdef _UCRT
> >> +#define _snprintf snprintf
> >> +#endif
> >
> > I don't understand this change.  Are you saying UCRT doesn't provide
> > _snprintf?  If so, why is the above needed only in cmdproxy?  w32*.c
> 
> As mingw ucrt patch mentions; MS ucrt provides snprintf so mingw does not
> provide one in ucrt.

Sorry, I don't understand what you mean by that.  MinGW only provides
some stuff that the MS libraries lack, so by "UCRT doesn't provide
_snprintf" I meant that the combination of MS ucrt and the MinGW
additions in UCRT mode doesn't provide _snprintf.

> I don't know why is it needed only there. From my original attemt, the linker
> missed reference to _snprintf only for cmdproxy, so I guess it is linked with
> the wrong library. I have looked at the Makefiles in nt directory, but as far as
> I understand linker flags comes from some included makefile (LDFLAGS=@ldflags@),
> so perhaps they have somehow wrong library elsewhere.

If you say "make V=1", you will see the complete compilation and link
commands, including any libraries that we are linking into the
executables.  If you spot some library that is present for temacs.exe,
but not for cmdproxy.exe, we can add that missing library to the link
command, or at least understand the nature of the problem and devise
some solution.  MinGW should come with a tool that allows you to see
what functions are exported by a DLL, so if you find which libraries
are not linked into cmdproxy, you could look at those libraries and
see which one of them, if any, provides _snprintf.  Can you please try
that and report the results?

> Yes, I agree, it is all about close_stream. Seems like it is all the same error:
> -1 (unspecified error). You can see the test from the patch.
> 
> I haven't seen the code for close_stream or msys patches; I will have to
> download and look at it; but it sounds plausible as you said that they probably
> don't clean up errno.

The source fore close_stream is in the lib/ subdirectory of the Emacs
source tree, so you should already have it.