Re: Failure building Emacs master on MSYS2 [MSYS2 PKG]

[Bruno Haible]

Collin Funk wrote:
> > Now, how about doing the same thing, in a different directory, with a
> > corrected configure command?
> >
> > ./configure --build=x86_64-w64-mingw32
> 
> This fails with an unsupported platform message from Emacs configure.ac.

That's not what I see.

What I did:
1. Downloaded the first "not-working" tarball pinpointed by Angelo.
   $ wget 
https://cgit.git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-71ee484cac3e0e5b68f006b4cca81c13ca6ce11e.tar.gz
2. Unpacked it, and ran
   $ ./autogen.sh
   on a GNU system.
3. Transferred these sources to an MSYS2 machine.
4. Installed makeinfo 4.13, from texinfo-4.13a.tar.gz from source;
   without it, the Emacs configure aborts.
5. In an MSYS2 mingw64 traditional environment (PATH contains /mingw64/bin),
   run
   $ ./configure --prefix=/usr/local/angelo --host=x86_64-w64-mingw32 \
                 --without-dbus --without-pop --without-native-compilation \
                 --with-gnutls=ifavailable CFLAGS=-O2
   $ make
   The build succeeds.
6. In an MSYS2 mingw64 ucrt environment (PATH contains /ucrt64/bin),
   run
   $ ./configure --prefix=/usr/local/angelo --host=x86_64-w64-mingw32 \
                 --without-dbus --without-pop --without-native-compilation \
                 --with-gnutls=ifavailable CFLAGS=-O2
   $ make
   The build succeeds.
7. In an MSYS2 mingw64 ucrt environment (PATH contains /ucrt64/bin),
   run
   $ ./configure --prefix=/usr/local/angelo --host=x86_64-pc-cygwin \
                 --without-dbus --without-pop --without-native-compilation \
                 --with-gnutls=ifavailable CFLAGS=-O2
   $ make
   This build fails already in the third compilation unit:

gcc -c    -MMD -MF deps/mktime.d -MP    -O2 -I. -I../src -I. -I../src   -o 
mktime.o mktime.c
In file included from C:/msys64/ucrt64/include/unistd.h:11,
                 from ./unistd.h:40,
                 from ./time.h:51,
                 from mktime.c:44:
../src/process.h:44:29: error: field 'header' has incomplete type
   44 |     union vectorlike_header header;
      |                             ^~~~~~
../src/process.h:47:5: error: unknown type name 'Lisp_Object'
   47 |     Lisp_Object tty_name;
      |     ^~~~~~~~~~~

   Which is really not astonishing, since the --host argument and the
   'Target' shown by "gcc -v" are not the same.

> However, I can reproduce the original error. It happens because in
> /usr/include/sys/_types.h there is:
> 
>     #define __need_size_t
>     #define __need_wint_t
>     #include <stddef.h>
> 
> And then in Gnulib's stddef.h.in, we do:
> 
>     #if (defined __need_wchar_t || defined __need_size_t                \
>          || defined __need_ptrdiff_t || defined __need_NULL             \
>          || defined __need_wint_t)                                      \
>         /* Avoid warning triggered by "gcc -std=gnu23 -Wsystem-headers" \
>            in GCC 13.3 and 14.2                                         \
>            <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870>.  */   \
>         && !@STDDEF_NOT_IDEMPOTENT@
> 
> Before doing #include_next <stddef.h>. On this platform
> @STDDEF_NOT_IDEMPOTENT@ is replaced with a 1. Therefore, the
> #include_next does not occur when it should.
> 
> I can confirm manually replacing it with a 0 allows Emacs to build.
> 
> Let me look through the commit history and that GCC bug report and see
> if I can think of a reasonable fix for this in Gnulib.

Before committing such a patch to Gnulib, please present it for review.
Rationale: As far as I have understood, the configuration that Angelo
and you are using is nonsensical and redundant. When Emacs can be built
for native Windows (supported) and for Cygwin (supported), why are
people trying to build it with a mix of both, called MSYS2, (unsupported,
according to Eli) that was only meant to be used for compiling essentially
the coreutils?

Bruno