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.