Compiling in mingw-ucrt runtime

Compiling in mingw-ucrt runtime

[Arthur Miller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: 0001-Check-for-actuall-errno-ignore-EINTR.patch --]
[-- Type: text/x-patch, Size: 1524 bytes --]

From ffa8edca7bb60ed06f23f769a5fac723b3bc020d Mon Sep 17 00:00:00 2001
From: Arthur Miller <arthur.miller@live.com>
Date: Thu, 22 Feb 2024 00:02:51 +0100
Subject: [PATCH] Check for actuall errno && ignore EINTR

---
 nt/cmdproxy.c | 3 +++
 src/sysdep.c  | 7 +++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

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
 /* We don't want to include stdio.h because we are already duplicating
    lots of it here */
 extern int _snprintf (char *buffer, size_t count, const char *format, ...);
diff --git a/src/sysdep.c b/src/sysdep.c
index 3a6829dd27a..5d294ca1bdf 100644
--- 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))
     {
       emacs_perror ("Write error to standard output");
       _exit (EXIT_FAILURE);
@@ -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);
+    }
 #endif /* __ANDROID__ */
 }
 \f
-- 
2.43.2


[-- Attachment #2: Type: text/plain, Size: 1420 bytes --]


I was a bit curios what is going on there. It turnes out, at least as I
understand, that the errors were not real errors, in most cases, so it seems
*almost* legit to brush them under carpet.

I printed out errors and what I saw were endless

"Write error to standard output: no error"

messages when native compiler run its batch jobs (amongst other).

Seems like close_stream in ucrt runtime does not return real errno but something
else.

Just checking if errno was set reduced almost everything; and I found that
comment in posix_close aboutt EINTR.

However; I am still not able to build emacs wihtout trolling away exit on
failure, because temacs fails. I get this error:

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?

Re: Compiling in mingw-ucrt runtime

[Po Lu via Emacs development discussions.]

Arthur Miller <arthur.miller@live.com> writes:

> diff --git a/src/sysdep.c b/src/sysdep.c
> index 3a6829dd27a..5d294ca1bdf 100644
> --- 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))
>      {
>        emacs_perror ("Write error to standard output");
>        _exit (EXIT_FAILURE);
> @@ -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);
> +    }
>  #endif /* __ANDROID__ */
>  }
>  \f

Why is this change necessary to build Emacs with a previously
unsupported C library?  If it is, shouldn't whatever problem it
circumvents be addressed in Gnulib (which provides close_stream), and
not in Emacs?

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> 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
files have a gazillion references to _snprintf -- aren't they affected
as well?

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.

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.

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

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

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

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

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

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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 meant they explained that in mingw runtime, msys/mingw provides their own
implementation of snprintf, while in ucrt runtime it comes from Microsoft. If I
remember well from the time I uset to write some win32 code, Microsoft used to prefix
all posix functions with and underscore, so snprintf turned into
_snprintf. Perhaps mingw just followed that convention by Microsoft. And now in
ucrt Microsoft don't underscore posix names? No idea really; just guessing. I am
not familiar with how msys/mingw folks do their patches and what is included and
what not. 

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

ok.

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

Ah, I see. Thanks I'll look there. 

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 23 Feb 2024 12:32:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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 meant they explained that in mingw runtime, msys/mingw provides their own
> implementation of snprintf, while in ucrt runtime it comes from Microsoft. If I
> remember well from the time I uset to write some win32 code, Microsoft used to prefix
> all posix functions with and underscore, so snprintf turned into
> _snprintf. Perhaps mingw just followed that convention by Microsoft. And now in
> ucrt Microsoft don't underscore posix names? No idea really; just guessing. I am
> not familiar with how msys/mingw folks do their patches and what is included and
> what not. 

I can understand that UCRT doesn't provide _snprintf, but then I don't
see why all the calls of _snprintf in w32.c and w32fns.c don't cause
the same problems in the UCRT build.  Perhaps indeed some library is
linked into temacs.exe but not into cmdproxy.exe.

> >> 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.
> 
> Ah, I see. Thanks I'll look there. 

Thanks.

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 23 Feb 2024 12:32:27 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> 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 meant they explained that in mingw runtime, msys/mingw provides their own
>> implementation of snprintf, while in ucrt runtime it comes from Microsoft. If I
>> remember well from the time I uset to write some win32 code, Microsoft used to prefix
>> all posix functions with and underscore, so snprintf turned into
>> _snprintf. Perhaps mingw just followed that convention by Microsoft. And now in
>> ucrt Microsoft don't underscore posix names? No idea really; just guessing. I am
>> not familiar with how msys/mingw folks do their patches and what is included and
>> what not. 
>
> I can understand that UCRT doesn't provide _snprintf, but then I don't
> see why all the calls of _snprintf in w32.c and w32fns.c don't cause
> the same problems in the UCRT build.  Perhaps indeed some library is
> linked into temacs.exe but not into cmdproxy.exe.

Ok; I have looked at close_stream :). Why is it clearing errno on prev_fail?

if (! fclose_fail)
  errno = 0;
      
I don't think it is meaningful to signal to client code that operation failed,
but clear the errno so the application can't figure out why and recover. But
perhaps I just don't understand the details. Anyway, I don't think that is the
problem here.

I think the problem is that different libraries are mixed. I am not 100%,
because I am not familiar with the build process, but what I see is that ldflags and
cflags seems quite different for temacs vs cmdproxy:

gcc  -mtune=generic  -fstrict-flex-arrays -Wall -Warith-conversion -Wdate-time
-Wdisabled-optimization -Wdouble-promotion -Wduplicated-cond -Wextra
-Wformat-signedness -Winit-self -Winvalid-pch -Wlogical-op
-Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes
-Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd
-Wpacked -Wpointer-arith -Wstrict-flex-arrays -Wstrict-prototypes
-Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types
-Wtrampolines -Wuninitialized -Wunknown-pragmas -Wunused-macros
-Wvariadic-macros -Wvector-operation-performance -Wwrite-strings
-Warray-bounds=2 -Wattribute-alias=2 -Wformat=2 -Wformat-truncation=2
-Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wuse-after-free=3
-Wvla-larger-than=4031 -Wno-missing-field-initializers -Wno-override-init
-Wno-sign-compare -Wno-type-limits -Wno-unused-parameter -Wno-format-nonliteral
-Wno-bidi-chars -Wno-pointer-sign  -I../src -I./../src -I../lib -I./../lib
-I. -I.   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/Users/arthu/repos/emsrc/ucrt-02-21/nt/inc -g3 -O2 -gdwarf-2 cmdproxy.c -o
cmdproxy.exe

gcc  -o temacs.exe.tmp \
  -Demacs  -I. -I. -I../lib -I../lib  -mtune=generic       -isystem C:/msys64/ucrt64/include/libxml2  -isystem C:/msys64/ucrt64/include/dbus-1.0 -isystem C:/msys64/ucrt64/lib/dbus-1.0/include      -isystem C:/msys64/ucrt64/include/webp      -isystem C:/msys64/ucrt64/include/harfbuzz -isystem C:/msys64/ucrt64/include/freetype2 -isystem C:/msys64/ucrt64/include/libpng16 -isystem C:/msys64/ucrt64/include/glib-2.0 -isystem C:/msys64/ucrt64/lib/glib-2.0/include   -MMD -MF deps/.d -MP     -isystem C:/msys64/ucrt64/include/p11-kit-1              -fstrict-flex-arrays -Wall -Warith-conversion -Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wduplicated-cond -Wextra -Wformat-signedness -Winit-self -Winvalid-pch -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnull-dereference -Wold-style-definition -Wopenmp-simd -Wpacked -Wpointer-arith -Wstrict-flex-arrays -Wstrict-prototypes -Wsuggest-attribute=noreturn -Wsuggest-final-methods -Wsuggest-final-types -Wtrampolines -Wuninitialized -Wunknown-pragmas -Wunused-macros -Wvariadic-macros -Wvector-operation-performance -Wwrite-strings -Warray-bounds=2 -Wattribute-alias=2 -Wformat=2 -Wformat-truncation=2 -Wimplicit-fallthrough=5 -Wshift-overflow=2 -Wuse-after-free=3 -Wvla-larger-than=4031 -Wno-missing-field-initializers -Wno-override-init -Wno-sign-compare -Wno-type-limits -Wno-unused-parameter -Wno-format-nonliteral -Wno-bidi-chars -Wno-pointer-sign -g3 -O2 -gdwarf-2   -Wl,-stack,0x00800000 -Wl,-heap,0x00100000 -Wl,-image-base,0x400000000 -Wl,-entry,__start -Wl,-Map,./temacs.map  \
  firstfile.o  dispnew.o frame.o scroll.o xdisp.o menu.o  window.o charset.o
coding.o category.o ccl.o character.o chartab.o bidi.o  term.o terminal.o
xfaces.o   dbusbind.o emacs.o keyboard.o macros.o keymap.o sysdep.o bignum.o
buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o cmds.o
casetab.o casefiddle.o indent.o search.o regex-emacs.o undo.o alloc.o pdumper.o
data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o sort.o font.o print.o
lread.o emacs-module.o syntax.o  bytecode.o comp.o dynlib.o process.o gnutls.o
callproc.o region-cache.o sound.o timefns.o atimer.o doprnt.o intervals.o
textprop.o composite.o xml.o lcms.o w32notify.o  profiler.o decompress.o
thread.o systhread.o sqlite.o  treesit.o itree.o      hbfont.o w32fns.o
w32menu.o w32reg.o w32font.o w32term.o w32xfns.o w32select.o w32uniscribe.o
w32cygwinx.o w32.o w32console.o w32heap.o w32inevt.o w32proc.o w32image.o
fontset.o fringe.o image.o        tparam.o    lastfile.o   ../lib/libgnu.a
emacs.res  -lwinmm -lusp10 -lgdi32 -lcomdlg32 -lmpr -lwinspool -lole32
-lcomctl32   -ldbus-1  -lgmp 

I have also tested to include <stdio.h> in cmdproxy.c; then I get conflicting
redefinition and conflicting declaration for printf and basically everything in
stdio:

cmdproxy.c:63:5: error: conflicting types for 'fprintf'; have 'int(void *, const char *, ...)'
   63 | int fprintf (HANDLE, const char *, ...);
      |     ^~~~~~~
C:/msys64/ucrt64/include/stdio.h:368:5: note: previous definition of 'fprintf' with type 'int(FILE *, const char *, ...)' {aka 'int(struct _iobuf *, const char *, ...)'}
  368 | int fprintf (FILE *__stream, const char *__format, ...)
      |     ^~~~~~~
cmdproxy.c:91:1: error: redefinition of 'printf'
   91 | printf (const char * msg, ...)
      | ^~~~~~
C:/msys64/ucrt64/include/stdio.h:379:5: note: previous definition of 'printf' with type 'int(const char *, ...)'
  379 | int printf (const char *__format, ...)
      |     ^~~~~~

Seems like conflict between two version of libraries and/or headers. I have
tried to see if I can change what build sees and to link with same libraries as
temacs gets linked to, but I haven't managed to get that happen :).

I have also a qeustion; I would like to understand better how Emacs get built,
so I wonder why does it include half of the gnulibc and core-utils in lib
directory? Is it just to get faster static executable, or in the case gnulibc is
not available or some other reason?

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Feb 2024 10:13:45 +0100
> 
> Ok; I have looked at close_stream :). Why is it clearing errno on prev_fail?
> 
> if (! fclose_fail)
>   errno = 0;
>       
> I don't think it is meaningful to signal to client code that operation failed,
> but clear the errno so the application can't figure out why and recover.

There are comments there which explain the rationale.  If you are
saying that in the UCRT build something goes wrong that violates the
assumptions of this code, please tell the details.  Specifically,
which of these three operations indicates a failure:

  const bool some_pending = (__fpending (stream) != 0);
  const bool prev_fail = (ferror (stream) != 0);
  const bool fclose_fail = (fclose (stream) != 0);

You can answer that question by printing the 3 values, or by stepping
through the code with GDB.

> But perhaps I just don't understand the details. Anyway, I don't
> think that is the problem here.
> 
> I think the problem is that different libraries are mixed. I am not 100%,
> because I am not familiar with the build process, but what I see is that ldflags and
> cflags seems quite different for temacs vs cmdproxy:

Of course, they are!  temacs is a large application with GUI
capabilities, and calls a lot of Windows APIs, whereas cmdproxy is a
relatively simple console application that just calls the shell.  The
question is: which of the libraries linked into temacs seem to define
_snprintf, or if none do, how does the linker resolve the calls to
_snprintf in w32.c, w32fns.c and sound.c.  If you cannot figure that
out by looking at the libraries, perhaps "nm -A" could help?  Here's
the command I would use for that:

   nm -A sound.o | fgrep snprintf

In my MinGW/MSVCRT build of Emacs, I get this output:

  (standard input):37:sound.o:         U __snprintf

What do you get?

> I have also tested to include <stdio.h> in cmdproxy.c; then I get conflicting
> redefinition and conflicting declaration for printf and basically everything in
> stdio:

That's not surprising, since the comments in cmdproxy.c say:

  /* We don't want to include stdio.h because we are already duplicating
     lots of it here */
  extern int _snprintf (char *buffer, size_t count, const char *format, ...);

So don't do that.

> I have also a qeustion; I would like to understand better how Emacs get built,
> so I wonder why does it include half of the gnulibc and core-utils in lib
> directory?

It isn't gnulibc or core-utils, it's Gnulib, the library that provides
implementations of functions missing from C libraries that are not
glibc.  Emacs uses Gnulib to avoid too many #ifdef's in its sources,
where some function needs to be used that is not guaranteed to exist
on all platforms -- in such cases we use the Gnulib replacement.

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sat, 24 Feb 2024 10:13:45 +0100
>> 
>> Ok; I have looked at close_stream :). Why is it clearing errno on prev_fail?
>> 
>> if (! fclose_fail)
>>   errno = 0;
>>       
>> I don't think it is meaningful to signal to client code that operation failed,
>> but clear the errno so the application can't figure out why and recover.
>
> There are comments there which explain the rationale.  If you are
> saying that in the UCRT build something goes wrong that violates the
> assumptions of this code, please tell the details.  Specifically,
> which of these three operations indicates a failure:
>
>   const bool some_pending = (__fpending (stream) != 0);
>   const bool prev_fail = (ferror (stream) != 0);
>   const bool fclose_fail = (fclose (stream) != 0);

prev_fail sometimes fail with Operation not permitted.
fclose fails always with -1

> You can answer that question by printing the 3 values, or by stepping
> through the code with GDB.

Yeah, I know Eli; thanks. :)

>> But perhaps I just don't understand the details. Anyway, I don't
>> think that is the problem here.
>> 
>> I think the problem is that different libraries are mixed. I am not 100%,
>> because I am not familiar with the build process, but what I see is that ldflags and
>> cflags seems quite different for temacs vs cmdproxy:
>
> Of course, they are!  temacs is a large application with GUI
> capabilities, and calls a lot of Windows APIs, whereas cmdproxy is a
> relatively simple console application that just calls the shell.  The

I didn't expect them to be identical in the sense they will link against all the
same libraries and have all the same command line switches.

I don't see -DUSE_CRT_DLL=1 in temacs object; so I am just suspecting there
are some different dlls from different places with same symbols in game, but I
don't know how the build works. Perhaps they are both linked to the same ucrt
runtime anyway. 

> question is: which of the libraries linked into temacs seem to define
> _snprintf, or if none do, how does the linker resolve the calls to
> _snprintf in w32.c, w32fns.c and sound.c.  If you cannot figure that

$ nm -a nt/cmdproxy.exe  | fgrep _snprintf
0000000140004060 D __imp_snprintf
0000000000000318 ? ucrt_snprintf.

$ nm -a src/sound.o | fgrep snprintf
0000000000000000 t _snprintf.constprop.0
                 U _vsnprintf

$ nm -a src/w32.o | fgrep snprintf
0000000000000bd0 t _snprintf
                 U _vsnprintf

$ nm -a src/w32fns.o | fgrep snprintf
                 U __mingw_vsnprintf
00000000000017d0 t _snprintf.constprop.0
                 U _vsnprintf
0000000000001800 t snprintf.constprop.0

How can I see which dll are they actually from? I tried with objdump but I
didn't got anything. Scanelf does not understand coff.

>> I have also tested to include <stdio.h> in cmdproxy.c; then I get conflicting
>> redefinition and conflicting declaration for printf and basically everything in
>> stdio:
>
> That's not surprising, since the comments in cmdproxy.c say:
>
>   /* We don't want to include stdio.h because we are already duplicating
>      lots of it here */
>   extern int _snprintf (char *buffer, size_t count, const char *format, ...);
>
> So don't do that.

Yes, I have seen that, and expected those to conflict; but there is much more
conflicting than just those defined in cmdproxy.c. Basically every symbol from
stdio is conflicting, not just those defined in cmdproxy itself. I think it is
fishy,but perhaps I am misunderstanding that. 

Can it be that fclose is trying to close a wrong pointer or something like that,
because pointer from one library is (wrongly) passed to a wrong library?

>> I have also a qeustion; I would like to understand better how Emacs get built,
>> so I wonder why does it include half of the gnulibc and core-utils in lib
>> directory?
>
> It isn't gnulibc or core-utils, it's Gnulib, the library that provides
> implementations of functions missing from C libraries that are not
> glibc.  Emacs uses Gnulib to avoid too many #ifdef's in its sources,
> where some function needs to be used that is not guaranteed to exist
> on all platforms -- in such cases we use the Gnulib replacement.

Ok. Thanks.

Another question: the build process compiles one lisp file at a time It takes
quite long time to recompile. Is there some special reason a separate Emacs
process is created per each Lisp file, instead of single Emacs process compiling
all lisp files in batch? Just so we can call make with -jN flag?

Re: Compiling in mingw-ucrt runtime

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Another question: the build process compiles one lisp file at a time
> It takes quite long time to recompile. Is there some special reason a
> separate Emacs process is created per each Lisp file, instead of
> single Emacs process compiling all lisp files in batch? Just so we can
> call make with -jN flag?

That, and also so that none of the compilation process is left to
chance, since otherwise Lisp files loaded during one file's compilation
might contaminate the compiler's environment for subsequent files and
create latent dependencies on their order or presence.

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 00:11:10 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There are comments there which explain the rationale.  If you are
> > saying that in the UCRT build something goes wrong that violates the
> > assumptions of this code, please tell the details.  Specifically,
> > which of these three operations indicates a failure:
> >
> >   const bool some_pending = (__fpending (stream) != 0);
> >   const bool prev_fail = (ferror (stream) != 0);
> >   const bool fclose_fail = (fclose (stream) != 0);
> 
> prev_fail sometimes fail with Operation not permitted.
> fclose fails always with -1

What is the value of errno before and after fclose, in particular when
ferror does NOT fail (i.e. prev_fail is false)?

> > question is: which of the libraries linked into temacs seem to define
> > _snprintf, or if none do, how does the linker resolve the calls to
> > _snprintf in w32.c, w32fns.c and sound.c.  If you cannot figure that
> 
> $ nm -a nt/cmdproxy.exe  | fgrep _snprintf
> 0000000140004060 D __imp_snprintf
> 0000000000000318 ? ucrt_snprintf.

The __imp_snprintf means it expects the function to be pulled from a
DLL.  Which is wrong, AFAIU; see below.

> $ nm -a src/sound.o | fgrep snprintf
> 0000000000000000 t _snprintf.constprop.0
>                  U _vsnprintf
> 
> $ nm -a src/w32.o | fgrep snprintf
> 0000000000000bd0 t _snprintf
>                  U _vsnprintf
> 
> $ nm -a src/w32fns.o | fgrep snprintf
>                  U __mingw_vsnprintf
> 00000000000017d0 t _snprintf.constprop.0
>                  U _vsnprintf
> 0000000000001800 t snprintf.constprop.0

OK, this means _snprintf in the UCRT case is defined by some header.
And indeed I see its definition in stdio.h, for UCRT only.  So I think
your original change was OK after all, and I have now installed it
with a comment explaining why.

> How can I see which dll are they actually from? I tried with objdump but I
> didn't got anything. Scanelf does not understand coff.

You should be able to use "nm -g SOME.DLL" to show the symbols
exported by that DLL; those marked "T" are functions.

But I don't think you need that: the above clearly tells us _snprintf
does NOT come from a DLL, its code is included in the executable
(that's what "t" means in the nm output), which can only mean it is
either defined inline in some header or in the program sources
themselves.

> Yes, I have seen that, and expected those to conflict; but there is much more
> conflicting than just those defined in cmdproxy.c. Basically every symbol from
> stdio is conflicting, not just those defined in cmdproxy itself. I think it is
> fishy,but perhaps I am misunderstanding that. 
> 
> Can it be that fclose is trying to close a wrong pointer or something like that,
> because pointer from one library is (wrongly) passed to a wrong library?

But the fclose problem does not happen in cmdproxy.exe, it is in
emacs.exe, right?  So this is not relevant to the fact that cmdproxy
doesn't include stdio.h.

> Another question: the build process compiles one lisp file at a time It takes
> quite long time to recompile. Is there some special reason a separate Emacs
> process is created per each Lisp file, instead of single Emacs process compiling
> all lisp files in batch?

Yes: we want to compile each Lisp file in a clean environment,
unchanged by loading any other Lisp files.

> Just so we can call make with -jN flag?

You can use -jN, and that speeds up the compilation quite a lot.  On
my system I use -j16, and I can bootstrap Emacs in under 4 min.

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Feb 2024 00:11:10 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > There are comments there which explain the rationale.  If you are
>> > saying that in the UCRT build something goes wrong that violates the
>> > assumptions of this code, please tell the details.  Specifically,
>> > which of these three operations indicates a failure:
>> >
>> >   const bool some_pending = (__fpending (stream) != 0);
>> >   const bool prev_fail = (ferror (stream) != 0);
>> >   const bool fclose_fail = (fclose (stream) != 0);
>> 
>> prev_fail sometimes fail with Operation not permitted.
>> fclose fails always with -1
>
> What is the value of errno before and after fclose, in particular when
> ferror does NOT fail (i.e. prev_fail is false)?

fclose *always* fail with -1. All calls to fclose are -1. I don't see any call
to fclose that does not return -1. Both when prev_fails is EPERM and when
prev_fail does not fail.

>> > question is: which of the libraries linked into temacs seem to define
>> > _snprintf, or if none do, how does the linker resolve the calls to
>> > _snprintf in w32.c, w32fns.c and sound.c.  If you cannot figure that
>> 
>> $ nm -a nt/cmdproxy.exe  | fgrep _snprintf
>> 0000000140004060 D __imp_snprintf
>> 0000000000000318 ? ucrt_snprintf.
>
> The __imp_snprintf means it expects the function to be pulled from a
> DLL.  Which is wrong, AFAIU; see below.
>
>> $ nm -a src/sound.o | fgrep snprintf
>> 0000000000000000 t _snprintf.constprop.0
>>                  U _vsnprintf
>> 
>> $ nm -a src/w32.o | fgrep snprintf
>> 0000000000000bd0 t _snprintf
>>                  U _vsnprintf
>> 
>> $ nm -a src/w32fns.o | fgrep snprintf
>>                  U __mingw_vsnprintf
>> 00000000000017d0 t _snprintf.constprop.0
>>                  U _vsnprintf
>> 0000000000001800 t snprintf.constprop.0
>
> OK, this means _snprintf in the UCRT case is defined by some header.
> And indeed I see its definition in stdio.h, for UCRT only.  So I think
> your original change was OK after all, and I have now installed it
> with a comment explaining why.
>
>> How can I see which dll are they actually from? I tried with objdump but I
>> didn't got anything. Scanelf does not understand coff.
>
> You should be able to use "nm -g SOME.DLL" to show the symbols
> exported by that DLL; those marked "T" are functions.
>
> But I don't think you need that: the above clearly tells us _snprintf
> does NOT come from a DLL, its code is included in the executable
> (that's what "t" means in the nm output), which can only mean it is
> either defined inline in some header or in the program sources
> themselves.

I understand; thanks. I guess I should learn nm tool.

Which one shold be correct than: should sydep.c use stuff from ucrt dll; or
should it use the built-in stuff?

>> Yes, I have seen that, and expected those to conflict; but there is much more
>> conflicting than just those defined in cmdproxy.c. Basically every symbol from
>> stdio is conflicting, not just those defined in cmdproxy itself. I think it is
>> fishy,but perhaps I am misunderstanding that. 
>> 
>> Can it be that fclose is trying to close a wrong pointer or something like that,
>> because pointer from one library is (wrongly) passed to a wrong library?
>
> But the fclose problem does not happen in cmdproxy.exe, it is in
> emacs.exe, right?  So this is not relevant to the fact that cmdproxy
> doesn't include stdio.h.

Yes, of course. There are really two problems here. I just hoped they are
related. By the way, a slight regression: since cmdproxy includes its own
windows.h; it does not hurt to add _win32_lean_and_mean above too?

>> Another question: the build process compiles one lisp file at a time It takes
>> quite long time to recompile. Is there some special reason a separate Emacs
>> process is created per each Lisp file, instead of single Emacs process compiling
>> all lisp files in batch?
>
> Yes: we want to compile each Lisp file in a clean environment,
> unchanged by loading any other Lisp files.

I understand. Thanks.

>> Just so we can call make with -jN flag?
>
> You can use -jN, and that speeds up the compilation quite a lot.  On
> my system I use -j16, and I can bootstrap Emacs in under 4 min.

Ha! :-)

$ time make bootstrap -j12

real    12m40.651s
user    2m46.900s
sys     1m19.613s

arthu@Emmi UCRT64 ~/repos/emsrc/ucrt-0225
$ nt/runemacs.exe &
[1] 36209

I have added all msys folders to antivirus exceptions and folder where I keep
sources. Perhaps I should add gcc and other tools to list of process exceptions?

13th Gen Intel(R) Core(TM) i5-1345U   1.60 GHz

I understand this laptop is not a monster gaming machine, but I don't think it
should be this painfully slow either.

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 11:19:58 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >   const bool some_pending = (__fpending (stream) != 0);
> >> >   const bool prev_fail = (ferror (stream) != 0);
> >> >   const bool fclose_fail = (fclose (stream) != 0);
> >> 
> >> prev_fail sometimes fail with Operation not permitted.
> >> fclose fails always with -1
> >
> > What is the value of errno before and after fclose, in particular when
> > ferror does NOT fail (i.e. prev_fail is false)?
> 
> fclose *always* fail with -1. All calls to fclose are -1. I don't see any call
> to fclose that does not return -1. Both when prev_fails is EPERM and when
> prev_fail does not fail.

OK, but I asked also about the value of errno _after_ fclose is called
and fails.  It's important for understanding why it fails.

> I understand; thanks. I guess I should learn nm tool.
> 
> Which one shold be correct than: should sydep.c use stuff from ucrt dll; or
> should it use the built-in stuff?

Sorry, I don't understand: what about sysdep.c?  If you are talking
about close_output_streams, then we are not done yet investigating why
close_stream fails in the UCRT build.  When we understand what happens
there, we can revisit the close_output_streams issue and decide how to
handle it.

> By the way, a slight regression: since cmdproxy includes its own
> windows.h; it does not hurt to add _win32_lean_and_mean above too?

Maybe, but why bother?

> > You can use -jN, and that speeds up the compilation quite a lot.  On
> > my system I use -j16, and I can bootstrap Emacs in under 4 min.
> 
> Ha! :-)
> 
> $ time make bootstrap -j12
> 
> real    12m40.651s
> user    2m46.900s
> sys     1m19.613s

Well, you have 1/3rd of execution units I have, so 12 min is
reasonable, especially if this is with native-compilation.

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 25 Feb 2024 11:19:58 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> >   const bool some_pending = (__fpending (stream) != 0);
>> >> >   const bool prev_fail = (ferror (stream) != 0);
>> >> >   const bool fclose_fail = (fclose (stream) != 0);
>> >> 
>> >> prev_fail sometimes fail with Operation not permitted.
>> >> fclose fails always with -1
>> >
>> > What is the value of errno before and after fclose, in particular when
>> > ferror does NOT fail (i.e. prev_fail is false)?
>> 
>> fclose *always* fail with -1. All calls to fclose are -1. I don't see any call
>> to fclose that does not return -1. Both when prev_fails is EPERM and when
>> prev_fail does not fail.
>
> OK, but I asked also about the value of errno _after_ fclose is called
> and fails.  It's important for understanding why it fails.

You got the ansewr: -1; always after fclose :). It seem to never succeed.

c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: No error
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified error: -1
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard output: Unidentified error: -1
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: Operation not permitted
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified error: -1
c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard output: Unidentified error: -1
Compilation finished.

I did this little abomination:

#include <fpending.h>
int
close_stream (FILE *stream)
{
  /* const int some_pending = (__fpending (stream) != 0); */
  /* const int prev_fail = (ferror (stream) != 0); */
  /* const int fclose_fail = (fclose (stream) != 0); */

  const int some_pending = __fpending (stream);
  emacs_perror ("FPENDING:");
  const int prev_fail    = ferror (stream);
  emacs_perror ("FPREV:");
  const int fclose_fail  = fclose (stream);
  emacs_perror ("FCLOSE:");
  /* Return an error indication if there was a previous failure or if
     fclose failed, with one exception: ignore an fclose failure if
     there was no previous error, no data remains to be flushed, and
     fclose failed with EBADF.  That can happen when a program like cp
     is invoked like this 'cp a b >&-' (i.e., with standard output
     closed) and doesn't generate any output (hence no previous error
     and nothing to be flushed).  */

  if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
    {
      if (! fclose_fail)
        errno = 0;
      return EOF;
    }

  return 0;
}

(moved it to sysdep.c)

Everytime native compiler compiles a file, and Emacs exits I get this, so I
guess it is from closing the process? So it perhaps has nothing to do
with snprintf at all?

>> I understand; thanks. I guess I should learn nm tool.
>> 
>> Which one shold be correct than: should sydep.c use stuff from ucrt dll; or
>> should it use the built-in stuff?
>
> Sorry, I don't understand: what about sysdep.c?  If you are talking
> about close_output_streams, then we are not done yet investigating why

I meant in general; should temacs/emacs also use snprintf/_vsnprintf
from ucrt runtime or one that comes with Emacs/gnulib? 

> close_stream fails in the UCRT build.  When we understand what happens
> there, we can revisit the close_output_streams issue and decide how to
> handle it.
>> By the way, a slight regression: since cmdproxy includes its own
>> windows.h; it does not hurt to add _win32_lean_and_mean above too?
>
> Maybe, but why bother?
>> > You can use -jN, and that speeds up the compilation quite a lot.  On
>> > my system I use -j16, and I can bootstrap Emacs in under 4 min.
>> 
>> Ha! :-)
>> 
>> $ time make bootstrap -j12
>> 
>> real    12m40.651s
>> user    2m46.900s
>> sys     1m19.613s
>
> Well, you have 1/3rd of execution units I have, so 12 min is
> reasonable, especially if this is with native-compilation.

So what are you saying: that thes "efficient cores" as intel sells them are just
paperweight? :-) Basically it is a dual-core machine than?

I think my old haswell i7 I have in my desktop is also much faster, but I am not
at home now, so I can't measure it.

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 12:40:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Arthur Miller <arthur.miller@live.com>
> >> Cc: emacs-devel@gnu.org
> >> Date: Sun, 25 Feb 2024 11:19:58 +0100
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> >   const bool some_pending = (__fpending (stream) != 0);
> >> >> >   const bool prev_fail = (ferror (stream) != 0);
> >> >> >   const bool fclose_fail = (fclose (stream) != 0);
> >> >> 
> >> >> prev_fail sometimes fail with Operation not permitted.
> >> >> fclose fails always with -1
> >> >
> >> > What is the value of errno before and after fclose, in particular when
> >> > ferror does NOT fail (i.e. prev_fail is false)?
> >> 
> >> fclose *always* fail with -1. All calls to fclose are -1. I don't see any call
> >> to fclose that does not return -1. Both when prev_fails is EPERM and when
> >> prev_fail does not fail.
> >
> > OK, but I asked also about the value of errno _after_ fclose is called
> > and fails.  It's important for understanding why it fails.
> 
> You got the ansewr: -1; always after fclose :). It seem to never succeed.
> 
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard output: Unidentified error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FPENDING:: No error
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: PREV-FAIL:: Operation not permitted
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: FCLOSE:: Unidentified error: -1
> c:\Users\arthu\repos\emsrc\ucrt-0225\src\emacs.exe: Write error to standard output: Unidentified error: -1
> Compilation finished.
> 
> I did this little abomination:
> 
> #include <fpending.h>
> int
> close_stream (FILE *stream)
> {
>   /* const int some_pending = (__fpending (stream) != 0); */
>   /* const int prev_fail = (ferror (stream) != 0); */
>   /* const int fclose_fail = (fclose (stream) != 0); */
> 
>   const int some_pending = __fpending (stream);
>   emacs_perror ("FPENDING:");
>   const int prev_fail    = ferror (stream);
>   emacs_perror ("FPREV:");
>   const int fclose_fail  = fclose (stream);
>   emacs_perror ("FCLOSE:");
>   /* Return an error indication if there was a previous failure or if
>      fclose failed, with one exception: ignore an fclose failure if
>      there was no previous error, no data remains to be flushed, and
>      fclose failed with EBADF.  That can happen when a program like cp
>      is invoked like this 'cp a b >&-' (i.e., with standard output
>      closed) and doesn't generate any output (hence no previous error
>      and nothing to be flushed).  */
> 
>   if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
>     {
>       if (! fclose_fail)
>         errno = 0;
>       return EOF;
>     }
> 
>   return 0;
> }
> 
> (moved it to sysdep.c)
> 
> Everytime native compiler compiles a file, and Emacs exits I get this, so I
> guess it is from closing the process?

Time to involve the Gnulib folks, I think.

Bruno, are you aware of these issues with MinGW UCRT builds?  Why does
fclose fail, leaving errno at -1?

> So it perhaps has nothing to do with snprintf at all?

It's unrelated to snprintf.

> >> I understand; thanks. I guess I should learn nm tool.
> >> 
> >> Which one shold be correct than: should sydep.c use stuff from ucrt dll; or
> >> should it use the built-in stuff?
> >
> > Sorry, I don't understand: what about sysdep.c?  If you are talking
> > about close_output_streams, then we are not done yet investigating why
> 
> I meant in general; should temacs/emacs also use snprintf/_vsnprintf
> from ucrt runtime or one that comes with Emacs/gnulib? 

We already use the snprintf from UCRT, because we include stdio.h.

> >> $ time make bootstrap -j12
> >> 
> >> real    12m40.651s
> >> user    2m46.900s
> >> sys     1m19.613s
> >
> > Well, you have 1/3rd of execution units I have, so 12 min is
> > reasonable, especially if this is with native-compilation.
> 
> So what are you saying: that thes "efficient cores" as intel sells them are just
> paperweight? :-) Basically it is a dual-core machine than?

It has about 12 execution units, AFAIU.

Re: Compiling in mingw-ucrt runtime

[Bruno Haible]

Eli Zaretskii wrote:
> > > OK, but I asked also about the value of errno _after_ fclose is called
> > > and fails.  It's important for understanding why it fails.

On native Windows, the value of errno, after fclose() fails, is undefined.
See here in the Gnulib documentation:
https://www.gnu.org/software/gnulib/manual/html_node/fclose.html

and here in the Microsoft documentation:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fclose-fcloseall
(it sets errno only if the argument was a NULL pointer).

> > int
> > close_stream (FILE *stream)
> > {
> >   ...
> >   if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
> >     {
> >       if (! fclose_fail)
> >         errno = 0;
> >       return EOF;
> >     }
> > 
> >   return 0;
> > }

This code assumes that errno has a reasonable value after fclose() fails,
and is thus not portable to native Windows.

Let me see what I can do about it on the Gnulib side...

> Why does fclose fail, leaving errno at -1?

I cannot tell why fclose() failed in the first place.

Bruno

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 15:11:22 +0100
> 
> Eli Zaretskii wrote:
> > > > OK, but I asked also about the value of errno _after_ fclose is called
> > > > and fails.  It's important for understanding why it fails.
> 
> On native Windows, the value of errno, after fclose() fails, is undefined.
> See here in the Gnulib documentation:
> https://www.gnu.org/software/gnulib/manual/html_node/fclose.html
> 
> and here in the Microsoft documentation:
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fclose-fcloseall
> (it sets errno only if the argument was a NULL pointer).

Strange that they claim that, because their sources tell a different
story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
what they say there is inaccurate?

> > Why does fclose fail, leaving errno at -1?
> 
> I cannot tell why fclose() failed in the first place.

Right, that was part of my question ;-)

Re: Compiling in mingw-ucrt runtime

[Bruno Haible]

Eli Zaretskii wrote:
> > On native Windows, the value of errno, after fclose() fails, is undefined.
> > See here in the Gnulib documentation:
> > https://www.gnu.org/software/gnulib/manual/html_node/fclose.html
> > 
> > and here in the Microsoft documentation:
> > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fclose-fcloseall
> > (it sets errno only if the argument was a NULL pointer).
> 
> Strange that they claim that, because their sources tell a different
> story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> what they say there is inaccurate?

Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.

Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
and 10.0.14393.0/ucrt/stdio/fclose.cpp
is that errno gets set to EINVAL if the stream argument is invalid,
and remains unchanged otherwise.

This is consistent with the two documentation pages that I cited.

Bruno

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 16:05:54 +0100
> 
> > Strange that they claim that, because their sources tell a different
> > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> > what they say there is inaccurate?
> 
> Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.

fclose.c doesn't, indeed, but it calls _close (in close.c), which
does.

> Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
> and 10.0.14393.0/ucrt/stdio/fclose.cpp
> is that errno gets set to EINVAL if the stream argument is invalid,
> and remains unchanged otherwise.

I do see errno being set in close.cpp, which fclose.cpp calls to do
the actual job.

Re: Compiling in mingw-ucrt runtime

[Bruno Haible]

On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
> > From: Bruno Haible <bruno@clisp.org>
> > Cc: arthur.miller@live.com, emacs-devel@gnu.org
> > Date: Sun, 25 Feb 2024 16:05:54 +0100
> > 
> > > Strange that they claim that, because their sources tell a different
> > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> > > what they say there is inaccurate?
> > 
> > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
> 
> fclose.c doesn't, indeed, but it calls _close (in close.c), which
> does.

OK, so when it calls _close() and that fails, errno gets set. Good.
Still, fclose() can also fail due to !inuse(stream), in which case errno does
not get set.

> > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
> > and 10.0.14393.0/ucrt/stdio/fclose.cpp
> > is that errno gets set to EINVAL if the stream argument is invalid,
> > and remains unchanged otherwise.
> 
> I do see errno being set in close.cpp, which fclose.cpp calls to do
> the actual job.

Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
which case errno does not get set.

Bruno

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> Date: Sun, 25 Feb 2024 16:32:59 +0100
> 
> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
> > > From: Bruno Haible <bruno@clisp.org>
> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
> > > 
> > > > Strange that they claim that, because their sources tell a different
> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> > > > what they say there is inaccurate?
> > > 
> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
> > 
> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
> > does.
> 
> OK, so when it calls _close() and that fails, errno gets set. Good.
> Still, fclose() can also fail due to !inuse(stream), in which case errno does
> not get set.
> 
> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
> > > is that errno gets set to EINVAL if the stream argument is invalid,
> > > and remains unchanged otherwise.
> > 
> > I do see errno being set in close.cpp, which fclose.cpp calls to do
> > the actual job.
> 
> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
> which case errno does not get set.

Yes, I agree that it doesn't set errno in all the cases where it
fails.  But that's a far cry from saying that errno is always
undefined after it fails.

And the question still stands why does it fail in Emacs in such a way.

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bruno Haible <bruno@clisp.org>
>> Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> Date: Sun, 25 Feb 2024 16:32:59 +0100
>> 
>> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
>> > > From: Bruno Haible <bruno@clisp.org>
>> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
>> > > 
>> > > > Strange that they claim that, because their sources tell a different
>> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
>> > > > what they say there is inaccurate?
>> > > 
>> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
>> > 
>> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
>> > does.
>> 
>> OK, so when it calls _close() and that fails, errno gets set. Good.
>> Still, fclose() can also fail due to !inuse(stream), in which case errno does
>> not get set.
>> 
>> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
>> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
>> > > is that errno gets set to EINVAL if the stream argument is invalid,
>> > > and remains unchanged otherwise.
>> > 
>> > I do see errno being set in close.cpp, which fclose.cpp calls to do
>> > the actual job.
>> 
>> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
>> which case errno does not get set.
>
> Yes, I agree that it doesn't set errno in all the cases where it
> fails.  But that's a far cry from saying that errno is always
> undefined after it fails.
>
> And the question still stands why does it fail in Emacs in such a way.

Just a short question: did you got anywhere further with this?

Where did you look at the source? Are they installed with their (MS) command
line tools or do I have to install the entire VS/Windows devkti for the sources?

Re: Compiling in mingw-ucrt runtime

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Bruno Haible <bruno@clisp.org>,  emacs-devel@gnu.org
> Date: Tue, 02 Apr 2024 17:30:25 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Bruno Haible <bruno@clisp.org>
> >> Cc: arthur.miller@live.com, emacs-devel@gnu.org
> >> Date: Sun, 25 Feb 2024 16:32:59 +0100
> >> 
> >> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
> >> > > From: Bruno Haible <bruno@clisp.org>
> >> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
> >> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
> >> > > 
> >> > > > Strange that they claim that, because their sources tell a different
> >> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
> >> > > > what they say there is inaccurate?
> >> > > 
> >> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
> >> > 
> >> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
> >> > does.
> >> 
> >> OK, so when it calls _close() and that fails, errno gets set. Good.
> >> Still, fclose() can also fail due to !inuse(stream), in which case errno does
> >> not get set.
> >> 
> >> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
> >> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
> >> > > is that errno gets set to EINVAL if the stream argument is invalid,
> >> > > and remains unchanged otherwise.
> >> > 
> >> > I do see errno being set in close.cpp, which fclose.cpp calls to do
> >> > the actual job.
> >> 
> >> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
> >> which case errno does not get set.
> >
> > Yes, I agree that it doesn't set errno in all the cases where it
> > fails.  But that's a far cry from saying that errno is always
> > undefined after it fails.
> >
> > And the question still stands why does it fail in Emacs in such a way.
> 
> Just a short question: did you got anywhere further with this?

You are asking me or Bruno?

I've been waiting for Bruno to come back and tell more about what
happens with UCRT in this case.

> Where did you look at the source? Are they installed with their (MS) command
> line tools or do I have to install the entire VS/Windows devkti for the sources?

If you are asking about UCRT sources, they are freely available on the
Internet, just search for them and you will find them promptly.
(AFAIU, you also get them if you install some version of Studio or
other, but I didn't install it.)

Re: Compiling in mingw-ucrt runtime

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Bruno Haible <bruno@clisp.org>,  emacs-devel@gnu.org
>> Date: Tue, 02 Apr 2024 17:30:25 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Bruno Haible <bruno@clisp.org>
>> >> Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> >> Date: Sun, 25 Feb 2024 16:32:59 +0100
>> >> 
>> >> On Sonntag, 25. Februar 2024 16:14:51 CET Eli Zaretskii wrote:
>> >> > > From: Bruno Haible <bruno@clisp.org>
>> >> > > Cc: arthur.miller@live.com, emacs-devel@gnu.org
>> >> > > Date: Sun, 25 Feb 2024 16:05:54 +0100
>> >> > > 
>> >> > > > Strange that they claim that, because their sources tell a different
>> >> > > > story, both for MSVCRT and for UCRT.  Or maybe your interpretation of
>> >> > > > what they say there is inaccurate?
>> >> > > 
>> >> > > Re MSVCRT: My reading of Vc7/crt/src/fclose.c is that it never sets errno.
>> >> > 
>> >> > fclose.c doesn't, indeed, but it calls _close (in close.c), which
>> >> > does.
>> >> 
>> >> OK, so when it calls _close() and that fails, errno gets set. Good.
>> >> Still, fclose() can also fail due to !inuse(stream), in which case errno does
>> >> not get set.
>> >> 
>> >> > > Re UCRT: My reading of ucrt-10.0.10240.0/stdio/fclose.cpp
>> >> > > and 10.0.14393.0/ucrt/stdio/fclose.cpp
>> >> > > is that errno gets set to EINVAL if the stream argument is invalid,
>> >> > > and remains unchanged otherwise.
>> >> > 
>> >> > I do see errno being set in close.cpp, which fclose.cpp calls to do
>> >> > the actual job.
>> >> 
>> >> Likewise here: Still, fclose() can also fail due to !stream.is_in_use(), in
>> >> which case errno does not get set.
>> >
>> > Yes, I agree that it doesn't set errno in all the cases where it
>> > fails.  But that's a far cry from saying that errno is always
>> > undefined after it fails.
>> >
>> > And the question still stands why does it fail in Emacs in such a way.
>> 
>> Just a short question: did you got anywhere further with this?
>
> You are asking me or Bruno?
>
> I've been waiting for Bruno to come back and tell more about what
> happens with UCRT in this case.

Anyone and no one in particular, just curious if you or someone else have found
what could be the problem.

>> Where did you look at the source? Are they installed with their (MS) command
>> line tools or do I have to install the entire VS/Windows devkti for the sources?
>
> If you are asking about UCRT sources, they are freely available on the

Yes. I got an impression you were looking at some Windows sources,
because of the path in this sentence of yours:

> My reading of Vc7/crt/src/fclose.c is that it never sets errno.


> Internet, just search for them and you will find them promptly.
> (AFAIU, you also get them if you install some version of Studio or
> other, but I didn't install it.)

I took a look now. The only one I found freely on GH is someone's private
repository, "huangqinjin", with some commits, by them, so I don't want
to download that one.

I don't see any official ucrt repository amongst the 6.2k on MS Github. Perhaps
it is there, but tucked under some other project.

On SX they say, ucrt sources are distributed with SDKs, so I guess I'll download
Windows SDK anyway. I wanted to spare myself of VS and their SDKs, it is
gigabytes of downloads I don't need otherwise.

Re: Compiling in mingw-ucrt runtime

[Benjamin Riefenstahl]

Hi Arthur,

Arthur Miller writes:
> Just checking if errno was set reduced almost everything; and I found
> that comment in posix_close aboutt EINTR.

Is this specific to UCRT?  In usual errno usage, errno is not garanteed
to be 0, because runtime functions do not reset it in case of success.
If there are no other errors, it often is set to ENOENT, from the time
when some file was searched along some PATH variable.

Regards, benny

Re: Compiling in mingw-ucrt runtime

[Benjamin Riefenstahl]

> Arthur Miller writes:
>> Just checking if errno was set reduced almost everything; and I found
>> that comment in posix_close aboutt EINTR.
>
> Is this specific to UCRT?  In usual errno usage, errno is not garanteed
> to be 0, because runtime functions do not reset it in case of success.
> If there are no other errors, it often is set to ENOENT, from the time
> when some file was searched along some PATH variable.

On second look, the implementation of close_stream looks fishy to me in
the first place.  Parts of the logic are too convoluted for me to
understand, at least one part does not look right at all.  I do not
think that one should build anything on its setting, not setting or
re-setting errno.