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.