Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Thu, 22 Feb 2024 01:01:17 +0100
>> 
>> diff --git a/nt/cmdproxy.c b/nt/cmdproxy.c
>> index 0500b653bb2..82592404d4c 100644
>> --- a/nt/cmdproxy.c
>> +++ b/nt/cmdproxy.c
>> @@ -38,6 +38,9 @@ #define DEFER_MS_W32_H
>>  #include <string.h>  /* strlen */
>>  #include <ctype.h>   /* isspace, isalpha */
>>  
>> +#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.

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.

Another thing I notice is that I still get "non functional Emacs" error even
when I apply their second patch, which is just a configure shortcut:

# We want to use sys/wait.h from nt/inc
# https://lists.gnu.org/archive/html/help-gnu-emacs/2023-05/msg00107.html
ac_cv_header_sys_wait_h=yes

> files have a gazillion references to _snprintf -- aren't they affected
> as well?

Seems not. So I think somehow some library get messed up; or something else.

> And if the problem is other than UCR not providing _snprintf, then
> what is the problem?
>
>> --- a/src/sysdep.c
>> +++ b/src/sysdep.c
>> @@ -2981,7 +2981,7 @@ close_output_streams (void)
>>    fflush (stderr);
>>    fflush (stdout);
>>  #else /* !__ANDROID__ */
>> -  if (close_stream (stdout) != 0)
>> +  if (close_stream (stdout) != 0 && errno && (errno != EINTR))
>
> Checking errno for being non-zero is probably okay, but it should be
> explicit: 'errno != 0'.  The EINTR stuff should not be there, since
> there's no EINTR on MS-Windows, at least AFAIK.

I am so unfamiliar with what msys/cygwin/etc do to emulate posix, so I just put
it to test. Yepp, seems it is not there.

> Still, I'd like first to understand why close_stream returns non-zero
> here.  Can you step into close_stream with a debugger, or add printf
> diagnostics there, and tell which of the conditions in close_stream
> fail to check out?  It is quite possible that Gnulib's close_stream
> doesn't currently support the UCRT quirks well enough, in which case
> the change should be in Gnulib, not in Emacs.
>
>> @@ -2993,7 +2993,10 @@ close_output_streams (void)
>>    if (err | (ADDRESS_SANITIZER
>>           ? fflush (stderr) != 0 || ferror (stderr)
>>           : close_stream (stderr) != 0))
>> -    _exit (EXIT_FAILURE);
>> +    {
>> +      if (errno && (errno != EINTR))
>> +    _exit (EXIT_FAILURE);
>> +    }
>
> This is again about close_stream, this time for stderr instead of
> stdout.  So once again, please tell what happens in close_stream in
> this case, and let's take it from there.
>
>> Seems like close_stream in ucrt runtime does not return real errno but 
>> something
>> else.
>
> We need to understand better what happens there.

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.

Thanks for the help. Sorry, didn't had time yesterday.

0001-test-close_stream-err.patch
Description: Text Data

>> cp -f temacs.exe bootstrap-emacs.exe
>> rm -f bootstrap-emacs.pdmp
>> ./temacs --batch  -l loadup --temacs=pbootstrap \
>>         --bin-dest /ucrt64/bin/ --eln-dest /ucrt64/lib/emacs/30.0.50/
>> C:\Users\arthu\repos\emsrc\ucrt-02-21\src\temacs.exe: Write error to 
>> standard output: No such file or directory
>> make[2]: *** [Makefile:1014: bootstrap-emacs.pdmp] Error 1
>> 
>> Question is which file or directory? Dump file? Bad path? Bad encoding?
>> Something in loadup.el or elsewhere?
>> 
>> If I comment away exit on failure as they do in mingw patch, than everything
>> builds and seemnigly works. However I have experienced one crash where system
>> killed Emacs, similar as those I have seen with the version from gnu ftp
>> (29.2_1).
>> 
>> How do I debug temacs bootstrap?
>
> You run the failing command under GDB, putting a breakpoint on the
> line that emits that error message, and when the breakpoint breaks,
> look around to see what happened and why.  In this case, the ENOENT
> value of errno is peculiar, since stdout is not redirected to any
> file, AFAIU, so why does close_stream report ENOENT?  One possible
> reason is that close_stream should zero out errno before it starts its
> processing, to avoid reporting a stale value of errno from some
> unrelated call.