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?