Re: Compiling in mingw-ucrt runtime

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

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.