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?