Re: Compiling in mingw-ucrt runtime

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

[-- Attachment #1: Type: text/plain, Size: 3623 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-test-close_stream-err.patch --]
[-- Type: text/x-patch, Size: 1636 bytes --]

From dac444f9e5276f9f8328617e293f7764b12168df Mon Sep 17 00:00:00 2001
From: Arthur Miller <arthur.miller@live.com>
Date: Fri, 23 Feb 2024 08:32:03 +0100
Subject: [PATCH] test close_stream err

---
 src/sysdep.c | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/src/sysdep.c b/src/sysdep.c
index 5d294ca1bdf..e91111d0e53 100644
--- a/src/sysdep.c
+++ b/src/sysdep.c
@@ -2981,7 +2981,9 @@ close_output_streams (void)
   fflush (stderr);
   fflush (stdout);
 #else /* !__ANDROID__ */
-  if (close_stream (stdout) != 0 && errno && (errno != EINTR))
+  errno = close_stream (stdout);
+  emacs_perror ("STDOUT STREAM");
+  if ((errno != -1) && (errno != 0))
     {
       emacs_perror ("Write error to standard output");
       _exit (EXIT_FAILURE);
@@ -2989,13 +2991,17 @@ close_output_streams (void)
 
   /* Do not close stderr if addresses are being sanitized, as the
      sanitizer might report to stderr after this function is invoked.  */
-  bool err = buferr && (fflush (buferr) != 0 || ferror (buferr));
-  if (err | (ADDRESS_SANITIZER
-	     ? fflush (stderr) != 0 || ferror (stderr)
-	     : close_stream (stderr) != 0))
+  errno = buferr && (fflush (buferr) != 0 || ferror (buferr));
+  if (errno | (ADDRESS_SANITIZER
+	       ? fflush (stderr) != 0 || ferror (stderr)
+	       : close_stream (stderr) != 0))
     {
-      if (errno && (errno != EINTR))
-	_exit (EXIT_FAILURE);
+      // close_stream will return -1; use old errno to build Emacs
+      if (errno != 0)
+	{
+	  emacs_perror ("STDERROR STREAM");
+	  _exit (EXIT_FAILURE);
+	}
     }
 #endif /* __ANDROID__ */
 }
-- 
2.43.2


[-- Attachment #3: Type: text/plain, Size: 1293 bytes --]



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