MinGW build on master fails with Error 127

MinGW build on master fails with Error 127

[Loreno Heer]

MinGW build on master fails with Error 127:

> make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
> rm -f bootstrap-emacs.pdmp
> ./temacs --batch  -l loadup --temacs=pbootstrap \
>         --bin-dest /home/User/emacs-master-x86_64-full/bin/ --eln-dest /home/User/emacs-master-x86_64-full/lib/emacs/30.0.50/
> make[2]: *** [Makefile:915: bootstrap-emacs.pdmp] Error 127
> make[2]: Leaving directory '/home/User/src/emacs/src'
> make[1]: *** [Makefile:544: src] Error 2
> make[1]: Leaving directory '/home/User/src/emacs'
> make[1]: Entering directory '/home/User/src/emacs'
> ***
> *** "make all" failed with exit status 2.
> ***
> *** You could try to:
> *** - run "make bootstrap", which might fix the problem
> *** - run "make V=1", which displays the full commands invoked by make,
> ***   to further investigate the problem
> ***
> make[1]: *** [Makefile:414: advice-on-failure] Error 2
> make[1]: Leaving directory '/home/User/src/emacs'
> make: *** [Makefile:370: all] Error 2


I already tried make bootstrap and
git reset --hard and git clean -dxf
with a new build. Still fails.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Loreno Heer <helohe@bluewin.ch>
> Date: Mon, 12 Dec 2022 16:26:44 +0100
> 
> MinGW build on master fails with Error 127:
> 
> > make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
> > rm -f bootstrap-emacs.pdmp
> > ./temacs --batch  -l loadup --temacs=pbootstrap \
> >         --bin-dest /home/User/emacs-master-x86_64-full/bin/ --eln-dest /home/User/emacs-master-x86_64-full/lib/emacs/30.0.50/
> > make[2]: *** [Makefile:915: bootstrap-emacs.pdmp] Error 127

AFAIK, "error 127" means "command not found".  Do you have temacs.exe
in the src directory?  Did you see any other warnings or errors during
the build?

Anyway, it doesn't fail here.

When was the last time the build fro master worked for you, and what
changed on your system since then?  Some libraries or the compiler got
updated, perhaps?

Re: MinGW build on master fails with Error 127

[Loreno Heer]

Yes, temacs is in the src directory. There were some warnings and notes
but no other errors. I just updated mingw and the git repo today. Here
is the full build output:

> $ make NATIVE_FULL_AOT=1 -j$(nproc)                                                                 make actual-all || make advice-on-failure make-target=all exit-status=$?
> make[1]: Entering directory '/home/User/src/emacs'
> make -C lib all
> make -C doc/lispref info
> make[2]: Entering directory '/home/User/src/emacs/doc/lispref'
> /usr/bin/mkdir -p ../../info
>   GEN      ../../info/elisp.info
> make[2]: Entering directory '/home/User/src/emacs/lib'
>   GEN      alloca.h
>   GEN      byteswap.h
>   GEN      errno.h
>   GEN      execinfo.h
>   GEN      getopt.h
>   GEN      getopt-cdefs.h
>   GEN      malloc/dynarray.gl.h
>   GEN      malloc/dynarray-skeleton.gl.h
>   GEN      ieee754.h
>   GEN      limits.h
>   GEN      stdckdint.h
>   GEN      stdint.h
>   GEN      string.h
>   GEN      sys/random.h
>   GEN      time.h
>   CC       fingerprint.o
>   CC       acl_entries.o
>   CC       memmem.o
>   CC       mktime.o
>   CC       binary-io.o
>   CC       c-ctype.o
>   CC       c-strcasecmp.o
>   CC       c-strncasecmp.o
>   CC       close-stream.o
>   CC       count-leading-zeros.o
>   CC       count-one-bits.o
>   CC       count-trailing-zeros.o
>   CC       md5-stream.o
>   CC       md5.o
>   CC       sha1.o
>   CC       sha256.o
>   CC       sha512.o
>   CC       dtoastr.o
>   CC       dtotimespec.o
>   CC       execinfo.o
>   CC       filemode.o
>   CC       filevercmp.o
>   CC       fpending.o
>   CC       getopt.o
>   CC       getopt1.o
>   CC       getrandom.o
>   CC       gettime.o
>   CC       gettimeofday.o
>   CC       malloc/dynarray_at_failure.o
> gettimeofday.c: In function 'gettimeofday':
> gettimeofday.c:101:42: warning: the comparison will always evaluate as 'true' for the address of 'GetSystemTimePreciseAsFileTime' will never be NULL [-Waddress]
>   101 |   if (GetSystemTimePreciseAsFileTimeFunc != NULL)
>       |                                          ^~
> In file included from C:/msys64/mingw64/include/winbase.h:36,
>                  from C:/msys64/mingw64/include/windows.h:70,
>                  from gettimeofday.c:29:
> C:/msys64/mingw64/include/sysinfoapi.h:63:26: note: 'GetSystemTimePreciseAsFileTime' declared here
>    63 |   WINBASEAPI VOID WINAPI GetSystemTimePreciseAsFileTime (LPFILETIME lpSystemTimeAsFileTime);
>       |                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   CC       malloc/dynarray_emplace_enlarge.o
>   CC       malloc/dynarray_finalize.o
>   CC       malloc/dynarray_resize.o
>   CC       malloc/dynarray_resize_clear.o
>   CC       memrchr.o
>   CC       mkostemp.o
>   CC       nstrftime.o
>   CC       qcopy-acl.o
>   CC       regex.o
>   CC       sig2str.o
>   CC       sigdescr_np.o
>   CC       stat-time.o
>   CC       stpcpy.o
>   CC       tempname.o
>   CC       time_r.o
>   CC       time_rz.o
>   CC       timegm.o
>   CC       timespec.o
>   CC       timespec-add.o
>   CC       timespec-sub.o
>   CC       u64.o
>   AR       libgnu.a
> make[2]: Leaving directory '/home/User/src/emacs/lib'
> make -C doc/lispintro info
> make[2]: Entering directory '/home/User/src/emacs/doc/lispintro'
>   GEN      ../../info/eintr.info
> make[2]: Leaving directory '/home/User/src/emacs/doc/lispintro'
> make -C doc/emacs info
>   GEN      info/dir
> make[2]: Entering directory '/home/User/src/emacs/doc/emacs'
>   GEN      ../../info/emacs.info
> make[2]: Leaving directory '/home/User/src/emacs/doc/lispref'
> make -C nt all
> make[2]: Entering directory '/home/User/src/emacs/nt'
>   RC       emacs.res
>   CCLD     addpm.exe
>   CCLD     cmdproxy.exe
> make[2]: Leaving directory '/home/User/src/emacs/doc/emacs'
>   CCLD     ddeclient.exe
>   CCLD     runemacs.exe
> make[2]: Leaving directory '/home/User/src/emacs/nt'
> make -C lib-src all
> make[2]: Entering directory '/home/User/src/emacs/lib-src'
>   CC       ntlib.o
>   RC       emacsclient.res
>   CC       pop.o
>   CCLD     etags.exe
>   CCLD     ctags.exe
>   CCLD     emacsclient.exe
>   CCLD     emacsclientw.exe
>   CCLD     ebrowse.exe
>   CCLD     hexl.exe
>   CCLD     movemail.exe
>   CCLD     make-docfile.exe
>   CCLD     make-fingerprint.exe
> make[2]: Leaving directory '/home/User/src/emacs/lib-src'
> make -C src BIN_DESTDIR=''/mingw64/bin/'' \
>          ELN_DESTDIR='/mingw64/lib/emacs/30.0.50/' all
> make[2]: Entering directory '/home/User/src/emacs/src'
>   GEN      lisp.mk
>   GEN      globals.h
>   GEN      buildobj.h
> make -C ../nt ../src/emacs.res
> make[3]: Entering directory '/home/User/src/emacs/nt'
>   RC       ../src/emacs.res
> make[3]: Leaving directory '/home/User/src/emacs/nt'
> make -C ../admin/charsets all
> make[3]: Entering directory '/home/User/src/emacs/admin/charsets'
>   GEN      ../../etc/charsets/8859-2.map
>   GEN      ../../etc/charsets/8859-3.map
>   GEN      ../../etc/charsets/8859-4.map
>   GEN      ../../etc/charsets/8859-5.map
>   GEN      ../../etc/charsets/8859-6.map
>   GEN      ../../etc/charsets/8859-7.map
>   GEN      ../../etc/charsets/8859-8.map
>   GEN      ../../etc/charsets/8859-9.map
>   GEN      ../../etc/charsets/8859-10.map
>   GEN      ../../etc/charsets/8859-11.map
>   GEN      ../../etc/charsets/8859-13.map
>   GEN      ../../etc/charsets/8859-14.map
>   GEN      ../../etc/charsets/8859-15.map
> make -C ../admin/unidata charscript.el
> make[3]: Entering directory '/home/User/src/emacs/admin/unidata'
>   GEN      ../../etc/charsets/8859-16.map
>   GEN      ../../lisp/international/charscript.el
> make[3]: Leaving directory '/home/User/src/emacs/admin/unidata'
> make -C ../admin/unidata emoji-zwj.el
> make[3]: Entering directory '/home/User/src/emacs/admin/unidata'
>   GEN      ../../etc/charsets/IBM037.map
>   GEN      ../../lisp/international/emoji-zwj.el
> make[3]: Leaving directory '/home/User/src/emacs/admin/unidata'
> make -C ../admin/charsets cp51932.el
> make[3]: Entering directory '/home/User/src/emacs/admin/charsets'
>   GEN      ../../etc/charsets/CP932-2BYTE.map
>   GEN      ../../etc/charsets/IBM038.map
>   GEN      ../../lisp/international/cp51932.el
>   GEN      ../../etc/charsets/IBM256.map
> make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
>   GEN      ../../etc/charsets/IBM273.map
>   GEN      ../../etc/charsets/IBM274.map
> make -C ../admin/charsets eucjp-ms.el
> make[3]: Entering directory '/home/User/src/emacs/admin/charsets'
>   GEN      ../../lisp/international/eucjp-ms.el
> make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
>   GEN      ../../etc/charsets/IBM275.map
>   GEN      ../../etc/charsets/IBM277.map
>   GEN      ../../etc/charsets/IBM278.map
>   CC       firstfile.o
>   GEN      ../../etc/charsets/IBM280.map
>   CC       dispnew.o
>   GEN      ../../etc/charsets/IBM281.map
>   GEN      ../../etc/charsets/IBM284.map
>   CC       frame.o
>   GEN      ../../etc/charsets/IBM285.map
>   GEN      ../../etc/charsets/IBM290.map
>   GEN      ../../etc/charsets/IBM297.map
>   GEN      ../../etc/charsets/IBM420.map
>   GEN      ../../etc/charsets/IBM423.map
>   GEN      ../../etc/charsets/IBM424.map
>   GEN      ../../etc/charsets/IBM437.map
>   GEN      ../../etc/charsets/IBM500.map
>   CC       scroll.o
>   GEN      ../../etc/charsets/IBM850.map
>   GEN      ../../etc/charsets/IBM851.map
>   GEN      ../../etc/charsets/IBM852.map
>   GEN      ../../etc/charsets/IBM855.map
>   GEN      ../../etc/charsets/IBM856.map
>   GEN      ../../etc/charsets/IBM857.map
>   GEN      ../../etc/charsets/IBM860.map
>   GEN      ../../etc/charsets/IBM861.map
>   GEN      ../../etc/charsets/IBM862.map
>   GEN      ../../etc/charsets/IBM863.map
>   GEN      ../../etc/charsets/IBM864.map
>   GEN      ../../etc/charsets/IBM865.map
>   CC       xdisp.o
>   GEN      ../../etc/charsets/IBM866.map
>   GEN      ../../etc/charsets/IBM868.map
>   GEN      ../../etc/charsets/IBM869.map
>   GEN      ../../etc/charsets/IBM870.map
>   GEN      ../../etc/charsets/IBM871.map
>   GEN      ../../etc/charsets/IBM874.map
>   CC       menu.o
>   GEN      ../../etc/charsets/IBM875.map
>   GEN      ../../etc/charsets/IBM880.map
>   GEN      ../../etc/charsets/IBM891.map
>   GEN      ../../etc/charsets/IBM903.map
>   GEN      ../../etc/charsets/IBM904.map
>   GEN      ../../etc/charsets/IBM905.map
>   GEN      ../../etc/charsets/IBM918.map
>   GEN      ../../etc/charsets/IBM1004.map
>   GEN      ../../etc/charsets/IBM1026.map
>   GEN      ../../etc/charsets/IBM1047.map
>   GEN      ../../etc/charsets/CP737.map
>   GEN      ../../etc/charsets/CP775.map
>   GEN      ../../etc/charsets/CP1125.map
>   GEN      ../../etc/charsets/CP1250.map
>   GEN      ../../etc/charsets/CP1251.map
>   GEN      ../../etc/charsets/CP1252.map
>   GEN      ../../etc/charsets/CP1253.map
>   GEN      ../../etc/charsets/CP1254.map
>   GEN      ../../etc/charsets/CP1255.map
>   GEN      ../../etc/charsets/CP1256.map
>   GEN      ../../etc/charsets/CP1257.map
>   GEN      ../../etc/charsets/CP1258.map
>   GEN      ../../etc/charsets/CP10007.map
>   GEN      ../../etc/charsets/CP720.map
>   GEN      ../../etc/charsets/CP858.map
>   GEN      ../../etc/charsets/GB2312.map
>   GEN      ../../etc/charsets/GBK.map
>   GEN      ../../etc/charsets/GB180302.map
>   GEN      ../../etc/charsets/BIG5.map
>   GEN      ../../etc/charsets/BIG5-HKSCS.map
>   GEN      ../../etc/charsets/CNS-1.map
>   GEN      ../../etc/charsets/CNS-2.map
>   GEN      ../../etc/charsets/CNS-3.map
>   GEN      ../../etc/charsets/CNS-4.map
>   GEN      ../../etc/charsets/CNS-5.map
>   GEN      ../../etc/charsets/CNS-6.map
>   GEN      ../../etc/charsets/CNS-7.map
>   GEN      ../../etc/charsets/CNS-F.map
>   GEN      ../../etc/charsets/JISX0201.map
>   GEN      ../../etc/charsets/JISX0208.map
>   GEN      ../../etc/charsets/JISX0212.map
>   GEN      ../../etc/charsets/JISX2132.map
>   GEN      ../../etc/charsets/JISC6226.map
>   GEN      ../../etc/charsets/JISX213A.map
>   GEN      ../../etc/charsets/KSC5601.map
>   GEN      ../../etc/charsets/KSC5636.map
>   GEN      ../../etc/charsets/JOHAB.map
>   GEN      ../../etc/charsets/KOI-8.map
>   GEN      ../../etc/charsets/KOI8-R.map
>   GEN      ../../etc/charsets/KOI8-U.map
>   GEN      ../../etc/charsets/KOI8-T.map
>   CC       window.o
>   GEN      ../../etc/charsets/ALTERNATIVNYJ.map
>   GEN      ../../etc/charsets/MIK.map
>   GEN      ../../etc/charsets/PTCP154.map
>   GEN      ../../etc/charsets/TIS-620.map
>   GEN      ../../etc/charsets/VISCII.map
>   GEN      ../../etc/charsets/VSCII.map
>   GEN      ../../etc/charsets/VSCII-2.map
>   CC       charset.o
>   GEN      ../../etc/charsets/KA-PS.map
>   GEN      ../../etc/charsets/KA-ACADEMY.map
>   GEN      ../../etc/charsets/HP-ROMAN8.map
>   GEN      ../../etc/charsets/NEXTSTEP.map
>   GEN      ../../etc/charsets/MACINTOSH.map
>   GEN      ../../etc/charsets/EBCDICUK.map
>   GEN      ../../etc/charsets/EBCDICUS.map
>   GEN      ../../etc/charsets/stdenc.map
>   GEN      ../../etc/charsets/symbol.map
>   GEN      ../../etc/charsets/CP949-2BYTE.map
>   GEN      ../../etc/charsets/BIG5-1.map
>   GEN      ../../etc/charsets/BIG5-2.map
>   GEN      ../../etc/charsets/MULE-ethiopic.map
>   GEN      ../../etc/charsets/MULE-ipa.map
>   GEN      ../../etc/charsets/MULE-is13194.map
>   GEN      ../../etc/charsets/MULE-sisheng.map
>   GEN      ../../etc/charsets/MULE-tibetan.map
>   GEN      ../../etc/charsets/MULE-lviscii.map
>   GEN      ../../etc/charsets/MULE-uviscii.map
>   GEN      ../../etc/charsets/GB180304.map
>   GEN      ../../etc/charsets/JISX2131.map
>   CC       coding.o
>   GEN      charsets.stamp
> make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
>   CC       category.o
>   CC       ccl.o
>   CC       character.o
>   CC       chartab.o
>   CC       bidi.o
>   CC       term.o
>   CC       terminal.o
>   CC       xfaces.o
>   CC       emacs.o
>   CC       keyboard.o
>   CC       macros.o
>   CC       keymap.o
>   CC       sysdep.o
>   CC       bignum.o
>   CC       buffer.o
>   CC       filelock.o
>   CC       insdel.o
>   CC       marker.o
>   CC       minibuf.o
>   CC       fileio.o
>   CC       dired.o
>   CC       cmds.o
>   CC       casetab.o
>   CC       casefiddle.o
>   CC       indent.o
>   CC       search.o
>   CC       regex-emacs.o
>   CC       undo.o
>   CC       alloc.o
>   CC       pdumper.o
>   CC       data.o
>   CC       doc.o
>   CC       editfns.o
>   CC       callint.o
>   CC       eval.o
>   CC       floatfns.o
>   CC       fns.o
>   CC       sort.o
>   CC       font.o
>   CC       print.o
>   CC       lread.o
>   CC       emacs-module.o
>   CC       syntax.o
>   CC       bytecode.o
>   CC       comp.o
>   CC       dynlib.o
>   CC       process.o
>   CC       gnutls.o
>   CC       callproc.o
>   CC       region-cache.o
> In file included from process.c:33:
> In function 'SDATA',
>     inlined from 'SSDATA' at lisp.h:1678:19,
>     inlined from 'create_process' at process.c:2254:40,
>     inlined from 'Fmake_process' at process.c:2059:7:
> lisp.h:1672:31: warning: array subscript 0 is outside array bounds of 'char[]' [-Warray-bounds]
>  1672 |   return XSTRING (string)->u.s.data;
>       |          ~~~~~~~~~~~~~~~~~~~~~^~~~~
> lisp.h:1672:31: warning: null pointer dereference [-Wnull-dereference]
>   CC       sound.o
>   CC       timefns.o
>   CC       atimer.o
>   CC       doprnt.o
> In file included from ./conf_post.h:38,
>                  from ./config.h:3000,
>                  from timefns.c:20:
> timefns.c: In function 'Fcurrent_cpu_time':
> C:/msys64/home/User/src/emacs/nt/inc/ms-w32.h:298:17: warning: implicit declaration of function 'sys_clock'; did you mean 'sys_close'? [-Wimplicit-function-declaration]
>   298 | #define clock   sys_clock
>       |                 ^~~~~~~~~
> timefns.c:1797:27: note: in expansion of macro 'clock'
>  1797 |   return Fcons (make_int (clock ()), make_int (CLOCKS_PER_SEC));
>       |                           ^~~~~
> C:/msys64/home/User/src/emacs/nt/inc/ms-w32.h:298:17: warning: nested extern declaration of 'sys_clock' [-Wnested-externs]
>   298 | #define clock   sys_clock
>       |                 ^~~~~~~~~
> timefns.c:1797:27: note: in expansion of macro 'clock'
>  1797 |   return Fcons (make_int (clock ()), make_int (CLOCKS_PER_SEC));
>       |                           ^~~~~
>   CC       intervals.o
>   CC       textprop.o
>   CC       composite.o
>   CC       xml.o
>   CC       lcms.o
>   CC       w32notify.o
>   CC       profiler.o
>   CC       decompress.o
>   CC       thread.o
>   CC       systhread.o
>   CC       sqlite.o
>   CC       treesit.o
>   CC       itree.o
>   CC       hbfont.o
>   CC       w32fns.o
>   CC       w32menu.o
>   CC       w32reg.o
>   CC       w32font.o
>   CC       w32term.o
>   CC       w32xfns.o
>   CC       w32select.o
>   CC       w32uniscribe.o
>   CC       w32cygwinx.o
>   CC       w32.o
>   CC       w32console.o
>   CC       w32heap.o
>   CC       w32inevt.o
> w32heap.c: In function 'getrlimit':
> w32heap.c:853:14: warning: 'm' may be used uninitialized [-Wmaybe-uninitialized]
>   853 |         if (!VirtualQuery ((LPCVOID) &m, &m, sizeof m))
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from C:/msys64/mingw64/include/winbase.h:25,
>                  from C:/msys64/mingw64/include/windows.h:70,
>                  from w32common.h:24,
>                  from w32heap.c:54:
> C:/msys64/mingw64/include/memoryapi.h:45:28: note: by argument 1 of type 'LPCVOID' {aka 'const void *'} to 'VirtualQuery' declared here
>    45 |   WINBASEAPI SIZE_T WINAPI VirtualQuery (LPCVOID lpAddress, PMEMORY_BASIC_INFORMATION lpBuffer, SIZE_T dwLength);
>       |                            ^~~~~~~~~~~~
> w32heap.c:844:34: note: 'm' declared here
>   844 |         MEMORY_BASIC_INFORMATION m;
>       |                                  ^
>   CC       w32proc.o
>   CC       w32image.o
>   CC       fontset.o
>   CC       fringe.o
>   CC       image.o
>   CC       json.o
>   CC       tparam.o
>   CC       lastfile.o
>   CCLD     temacs.exe
>   GEN      ../etc/DOC
> /usr/bin/mkdir -p ../etc
> make -C ../lisp update-subdirs
> make[3]: Entering directory '/home/User/src/emacs/lisp'
> make[3]: Leaving directory '/home/User/src/emacs/lisp'
> cp -f temacs.exe bootstrap-emacs.exe
> rm -f bootstrap-emacs.pdmp
> ./temacs --batch  -l loadup --temacs=pbootstrap \
>         --bin-dest /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/
> make[2]: *** [Makefile:915: bootstrap-emacs.pdmp] Error 127
> make[2]: Leaving directory '/home/User/src/emacs/src'
> make[1]: *** [Makefile:544: src] Error 2
> make[1]: Leaving directory '/home/User/src/emacs'
> make[1]: Entering directory '/home/User/src/emacs'
> ***
> *** "make all" failed with exit status 2.
> ***
> *** You could try to:
> *** - run "make bootstrap", which might fix the problem
> *** - run "make V=1", which displays the full commands invoked by make,
> ***   to further investigate the problem
> ***
> make[1]: *** [Makefile:414: advice-on-failure] Error 2
> make[1]: Leaving directory '/home/User/src/emacs'
> make: *** [Makefile:370: all] Error 2


On 12.12.2022 16:40, Eli Zaretskii wrote:
>> From: Loreno Heer <helohe@bluewin.ch>
>> Date: Mon, 12 Dec 2022 16:26:44 +0100
>>
>> MinGW build on master fails with Error 127:
>>
>>> make[3]: Leaving directory '/home/User/src/emacs/admin/charsets'
>>> rm -f bootstrap-emacs.pdmp
>>> ./temacs --batch  -l loadup --temacs=pbootstrap \
>>>         --bin-dest /home/User/emacs-master-x86_64-full/bin/ --eln-dest /home/User/emacs-master-x86_64-full/lib/emacs/30.0.50/
>>> make[2]: *** [Makefile:915: bootstrap-emacs.pdmp] Error 127
> 
> AFAIK, "error 127" means "command not found".  Do you have temacs.exe
> in the src directory?  Did you see any other warnings or errors during
> the build?
> 
> Anyway, it doesn't fail here.
> 
> When was the last time the build fro master worked for you, and what
> changed on your system since then?  Some libraries or the compiler got
> updated, perhaps?

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 16:44:02 +0100
> Cc: emacs-devel@gnu.org
> From: Loreno Heer <helohe@bluewin.ch>
> 
> Yes, temacs is in the src directory. There were some warnings and notes
> but no other errors. I just updated mingw and the git repo today.

Which parts of MinGW got updated?  Did Make get updated? or Bash?

> Here is the full build output:

I see nothing out of ordinary here, except the final failure.

What happens if you run this command:

 ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/

manually, from the MSYS Bash prompt in the src directory -- does it
succeed?

Re: MinGW build on master fails with Error 127

[Loreno Heer]

On 12.12.2022 16:56, Eli Zaretskii wrote:
>> Date: Mon, 12 Dec 2022 16:44:02 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>> Yes, temacs is in the src directory. There were some warnings and notes
>> but no other errors. I just updated mingw and the git repo today.
> 
> Which parts of MinGW got updated?  Did Make get updated? or Bash?

[2022-12-12T12:35:19+0100] [PACMAN] Running 'pacman -Syuu'
[2022-12-12T12:35:19+0100] [PACMAN] synchronizing package lists
[2022-12-12T12:35:36+0100] [PACMAN] starting core system upgrade
[2022-12-12T12:37:14+0100] [ALPM] transaction started
[2022-12-12T12:37:16+0100] [ALPM] upgraded bash (5.1.016-1 -> 5.2.009-1)
[2022-12-12T12:37:18+0100] [ALPM] upgraded filesystem (2022.01-5 ->
2022.01-7)
[2022-12-12T12:37:18+0100] [ALPM] upgraded mintty (1~3.6.1-2 -> 1~3.6.2-1)
[2022-12-12T12:37:19+0100] [ALPM] upgraded msys2-runtime (3.3.6-2 ->
3.3.6-6)
[2022-12-12T12:37:19+0100] [ALPM] upgraded msys2-runtime-devel (3.3.6-2
-> 3.3.6-6)
[2022-12-12T12:37:19+0100] [ALPM] warning:
/etc/pacman.d/mirrorlist.mingw64 installed as
/etc/pacman.d/mirrorlist.mingw64.pacnew
[2022-12-12T12:37:19+0100] [ALPM] warning:
/etc/pacman.d/mirrorlist.ucrt64 installed as
/etc/pacman.d/mirrorlist.ucrt64.pacnew
[2022-12-12T12:37:19+0100] [ALPM] upgraded pacman-mirrors (20220205-1 ->
20221016-1)
[2022-12-12T12:37:23+0100] [ALPM] upgraded pacman (6.0.1-18 -> 6.0.1-25)
[2022-12-12T12:37:23+0100] [ALPM] transaction completed
[2022-12-12T12:40:50+0100] [PACMAN] Running 'pacman -Syuu'
[2022-12-12T12:40:50+0100] [PACMAN] synchronizing package lists
[2022-12-12T12:41:07+0100] [PACMAN] starting core system upgrade
[2022-12-12T12:41:07+0100] [PACMAN] starting full system upgrade
[2022-12-12T12:53:44+0100] [ALPM] transaction started
[2022-12-12T12:53:44+0100] [ALPM] upgraded libexpat (2.4.9-1 -> 2.5.0-1)
[2022-12-12T12:53:44+0100] [ALPM] upgraded libffi (3.4.3-1 -> 3.4.4-1)
[2022-12-12T12:53:44+0100] [ALPM] upgraded liblzma (5.2.7-1 -> 5.2.9-1)
[2022-12-12T12:53:44+0100] [ALPM] upgraded zlib (1.2.12-2 -> 1.2.13-1)
[2022-12-12T12:53:44+0100] [ALPM] upgraded libopenssl (1.1.1.q-1 ->
1.1.1.s-1)
[2022-12-12T12:53:44+0100] [ALPM] upgraded libreadline (8.1.002-2 ->
8.2.001-1)
[2022-12-12T12:53:53+0100] [ALPM] upgraded tcl (8.6.10-1 -> 8.6.12-1)
[2022-12-12T12:53:53+0100] [ALPM] upgraded libsqlite (3.39.4-1 -> 3.40.0-1)
[2022-12-12T12:54:43+0100] [ALPM] upgraded python (3.10.6-1 -> 3.10.9-1)
[2022-12-12T12:54:51+0100] [ALPM] upgraded coreutils (8.32-4 -> 8.32-5)
[2022-12-12T12:54:51+0100] [ALPM] upgraded libxml2 (2.10.2-1 -> 2.10.3-2)
[2022-12-12T12:54:53+0100] [ALPM] upgraded asciidoc (9.1.1-2 -> 10.2.0-1)
[2022-12-12T12:55:03+0100] [ALPM] upgraded binutils (2.37-5 -> 2.39-2)
[2022-12-12T12:55:10+0100] [ALPM] upgraded bison (3.8.2-3 -> 3.8.2-4)
[2022-12-12T12:55:10+0100] [ALPM] upgraded bsdtar (3.6.1-2 -> 3.6.2-2)
[2022-12-12T12:55:12+0100] [ALPM] upgraded openssl (1.1.1.q-1 -> 1.1.1.s-1)
[2022-12-12T12:55:13+0100] [ALPM] upgraded sed (4.8-3 -> 4.9-1)
[2022-12-12T12:55:13+0100] [ALPM] upgraded libcrypt (2.1-3 -> 2.1-4)
[2022-12-12T12:55:13+0100] [ALPM] upgraded less (608-1 -> 608-2)
[2022-12-12T12:55:13+0100] [ALPM] upgraded info (6.8-4 -> 7.0.1-1)
[2022-12-12T12:55:15+0100] [ALPM] upgraded ca-certificates (20211016-1
-> 20211016-2)
[2022-12-12T12:55:16+0100] [ALPM] upgraded libdb (5.3.28-3 -> 5.3.28-4)
[2022-12-12T12:55:17+0100] [ALPM] upgraded libedit (20210910_3.1-1 ->
20210910_3.1-2)
[2022-12-12T12:55:17+0100] [ALPM] upgraded heimdal-libs (7.7.0-3 -> 7.8.0-2)
[2022-12-12T12:55:18+0100] [ALPM] upgraded libunistring (1.0-1 -> 1.1-2)
[2022-12-12T12:55:18+0100] [ALPM] upgraded libidn2 (2.3.3-1 -> 2.3.4-2)
[2022-12-12T12:55:19+0100] [ALPM] upgraded libnghttp2 (1.50.0-1 -> 1.51.0-1)
[2022-12-12T12:55:19+0100] [ALPM] upgraded libpsl (0.21.1-4 -> 0.21.1-5)
[2022-12-12T12:55:20+0100] [ALPM] upgraded libssh2 (1.10.0-1 -> 1.10.0-2)
[2022-12-12T12:55:20+0100] [ALPM] upgraded libcurl (7.85.0-2 -> 7.86.0-1)
[2022-12-12T12:55:24+0100] [ALPM] upgraded curl (7.85.0-2 -> 7.86.0-1)
[2022-12-12T12:55:24+0100] [ALPM] upgraded db (5.3.28-3 -> 5.3.28-4)
[2022-12-12T12:55:24+0100] [ALPM] upgraded diffstat (1.64-1 -> 1.65-1)
[2022-12-12T12:55:25+0100] [ALPM] upgraded diffutils (3.8-3 -> 3.8-4)
[2022-12-12T12:55:26+0100] [ALPM] upgraded expat (2.4.9-1 -> 2.5.0-1)
[2022-12-12T12:55:27+0100] [ALPM] upgraded flex (2.6.4-2 -> 2.6.4-3)
[2022-12-12T12:55:27+0100] [ALPM] upgraded mpfr (4.1.0.p13-1 -> 4.1.1.p1-1)
[2022-12-12T12:55:29+0100] [ALPM] upgraded gawk (5.1.1-1 -> 5.2.1-1)
[2022-12-12T12:55:49+0100] [ALPM] upgraded libguile (3.0.8-2 -> 3.0.8-3)
[2022-12-12T12:55:50+0100] [ALPM] upgraded gdb (11.1-3 -> 11.1-4)
[2022-12-12T12:55:50+0100] [ALPM] upgraded libargp (20110921-3 ->
20110921-4)
[2022-12-12T12:55:50+0100] [ALPM] upgraded getent (2.18.90-3 -> 2.18.90-4)
[2022-12-12T12:55:52+0100] [ALPM] warning: /etc/nanorc installed as
/etc/nanorc.pacnew
[2022-12-12T12:55:52+0100] [ALPM] upgraded nano (6.4-1 -> 7.0-1)
[2022-12-12T12:56:00+0100] [ALPM] upgraded heimdal (7.7.0-3 -> 7.8.0-2)
[2022-12-12T12:56:01+0100] [ALPM] upgraded openssh (8.9p1-3 -> 9.1p1-1)
[2022-12-12T12:56:32+0100] [ALPM] upgraded perl (5.32.1-2 -> 5.36.0-1)
[2022-12-12T12:56:33+0100] [ALPM] upgraded perl-Clone (0.45-2 -> 0.45-3)
[2022-12-12T12:56:37+0100] [ALPM] upgraded perl-URI (5.10-1 -> 5.16-1)
[2022-12-12T12:56:38+0100] [ALPM] upgraded perl-HTTP-Message (6.36-1 ->
6.44-1)
[2022-12-12T12:56:39+0100] [ALPM] upgraded perl-HTML-Parser (3.78-1 ->
3.80-1)
[2022-12-12T12:56:43+0100] [ALPM] upgraded perl-libwww (6.60-1 -> 6.67-1)
[2022-12-12T12:56:49+0100] [ALPM] upgraded perl-MIME-tools (5.509-1 ->
5.510-1)
[2022-12-12T12:56:50+0100] [ALPM] upgraded perl-TermReadKey (2.38-2 ->
2.38-4)
[2022-12-12T12:56:56+0100] [ALPM] upgraded perl-Net-SSLeay (1.92-1 ->
1.92-2)
[2022-12-12T12:56:57+0100] [ALPM] upgraded perl-IO-Socket-SSL (2.075-1
-> 2.077-1)
[2022-12-12T12:57:04+0100] [ALPM] upgraded git (2.38.0-1 -> 2.38.1-1)
[2022-12-12T12:57:07+0100] [ALPM] upgraded glib2 (2.72.2-2 -> 2.74.3-1)
[2022-12-12T12:57:07+0100] [ALPM] upgraded libffi-devel (3.4.3-1 -> 3.4.4-1)
[2022-12-12T12:57:08+0100] [ALPM] installed pcre2-devel (10.40-1)
[2022-12-12T12:57:08+0100] [ALPM] upgraded zlib-devel (1.2.12-2 -> 1.2.13-1)
[2022-12-12T12:57:13+0100] [ALPM] upgraded glib2-devel (2.72.2-2 ->
2.74.3-1)
[2022-12-12T12:57:14+0100] [ALPM] upgraded libgnutls (3.7.8-1 -> 3.7.8-2)
[2022-12-12T12:57:14+0100] [ALPM] upgraded libksba (1.6.1-1 -> 1.6.2-1)
[2022-12-12T12:57:17+0100] [ALPM] upgraded gnupg (2.2.39-1 -> 2.2.40-1)
[2022-12-12T12:57:22+0100] [ALPM-SCRIPTLET] ==> Appending keys from
msys2.gpg...
[2022-12-12T12:57:23+0100] [ALPM-SCRIPTLET] ==> Updating trust database...
[2022-12-12T12:57:23+0100] [ALPM-SCRIPTLET] gpg: no need for a trustdb check
[2022-12-12T12:57:24+0100] [ALPM] upgraded gperf (3.1-4 -> 3.1-5)
[2022-12-12T12:57:24+0100] [ALPM] upgraded libpcre (8.45-1 -> 8.45-3)
[2022-12-12T12:57:25+0100] [ALPM] upgraded grep (1~3.0-3 -> 1~3.0-6)
[2022-12-12T12:57:32+0100] [ALPM] upgraded groff (1.22.4-3 -> 1.22.4-4)
[2022-12-12T12:57:32+0100] [ALPM] upgraded libcrypt-devel (2.1-3 -> 2.1-4)
[2022-12-12T12:57:32+0100] [ALPM] upgraded libedit-devel (20210910_3.1-1
-> 20210910_3.1-2)
[2022-12-12T12:57:33+0100] [ALPM] upgraded libdb-devel (5.3.28-3 ->
5.3.28-4)
[2022-12-12T12:57:33+0100] [ALPM] upgraded libsqlite-devel (3.39.4-1 ->
3.40.0-1)
[2022-12-12T12:57:39+0100] [ALPM] upgraded heimdal-devel (7.7.0-3 ->
7.8.0-2)
[2022-12-12T12:57:41+0100] [ALPM] upgraded perl-Locale-Gettext (1.07-7
-> 1.07-9)
[2022-12-12T12:57:42+0100] [ALPM] upgraded help2man (1.48.5-1 -> 1.49.2-1)
[2022-12-12T12:57:49+0100] [ALPM] upgraded perl-XML-Parser (2.46-3 ->
2.46-4)
[2022-12-12T12:57:49+0100] [ALPM] upgraded intltool (0.51.0-2 -> 0.51.0-3)
[2022-12-12T12:57:52+0100] [ALPM] upgraded irssi (1.2.3-1 -> 1.4.3-1)
[2022-12-12T12:57:52+0100] [ALPM] upgraded libarchive (3.6.1-2 -> 3.6.2-2)
[2022-12-12T12:57:52+0100] [ALPM] upgraded libatomic_ops (7.6.12-1 ->
7.6.14-1)
[2022-12-12T12:57:52+0100] [ALPM] upgraded libidn2-devel (2.3.3-1 ->
2.3.4-2)
[2022-12-12T12:57:52+0100] [ALPM] upgraded libgnutls-devel (3.7.8-1 ->
3.7.8-2)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libltdl (2.4.6-14 -> 2.4.7-3)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libpcre16 (8.45-1 -> 8.45-3)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libpcre32 (8.45-1 -> 8.45-3)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libpcrecpp (8.45-1 -> 8.45-3)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libpcreposix (8.45-1 -> 8.45-3)
[2022-12-12T12:57:53+0100] [ALPM] upgraded libreadline-devel (8.1.002-2
-> 8.2.001-1)
[2022-12-12T12:57:54+0100] [ALPM] upgraded libtool (2.4.6-14 -> 2.4.7-3)
[2022-12-12T12:57:54+0100] [ALPM] upgraded libunrar (6.1.4-1 -> 6.2.2-1)
[2022-12-12T12:57:54+0100] [ALPM] upgraded libunrar-devel (6.1.4-1 ->
6.2.2-1)
[2022-12-12T12:57:55+0100] [ALPM] upgraded libutil-linux (2.35.2-1 ->
2.35.2-3)
[2022-12-12T12:57:55+0100] [ALPM] upgraded libutil-linux-devel (2.35.2-1
-> 2.35.2-3)
[2022-12-12T12:57:57+0100] [ALPM] upgraded libxml2-python (2.10.2-1 ->
2.10.3-2)
[2022-12-12T12:57:58+0100] [ALPM] upgraded make (4.3-3 -> 4.4-1)
[2022-12-12T12:57:58+0100] [ALPM] upgraded man-db (2.10.2-2 -> 2.10.2-3)
[2022-12-12T12:57:59+0100] [ALPM] upgraded ninja (1.11.0-1 -> 1.11.1-1)
[2022-12-12T12:58:10+0100] [ALPM] upgraded meson (0.63.1-1 -> 0.64.1-1)
[2022-12-12T12:58:10+0100] [ALPM] upgraded mingw-w64-x86_64-mpfr
(4.1.0.p13-1 -> 4.1.1.p1-1)
[2022-12-12T12:58:10+0100] [ALPM] upgraded mingw-w64-x86_64-mpc (1.2.1-1
-> 1.3.0-1)
[2022-12-12T12:58:11+0100] [ALPM] upgraded
mingw-w64-x86_64-libwinpthread-git (10.0.0.r113.g57fd0b77a-1 ->
10.0.0.r157.gd295924f0-1)
[2022-12-12T12:58:11+0100] [ALPM] upgraded mingw-w64-x86_64-gcc-libs
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T12:58:15+0100] [ALPM] upgraded
mingw-w64-x86_64-vulkan-headers (1.3.231-1 -> 1.3.237-1)
[2022-12-12T12:58:16+0100] [ALPM] upgraded
mingw-w64-x86_64-vulkan-loader (1.3.231-1 -> 1.3.237-1)
[2022-12-12T12:58:26+0100] [ALPM] upgraded mingw-w64-x86_64-SDL2
(2.24.1-1 -> 2.26.1-1)
[2022-12-12T12:58:27+0100] [ALPM] upgraded mingw-w64-x86_64-zlib
(1.2.13-1 -> 1.2.13-2)
[2022-12-12T12:58:30+0100] [ALPM] upgraded mingw-w64-x86_64-pcre2
(10.40-1 -> 10.41-1)
[2022-12-12T12:58:30+0100] [ALPM] upgraded mingw-w64-x86_64-libffi
(3.4.3-1 -> 3.4.4-1)
[2022-12-12T12:58:31+0100] [ALPM] upgraded mingw-w64-x86_64-expat
(2.4.9-1 -> 2.5.0-1)
[2022-12-12T12:59:19+0100] [ALPM] upgraded mingw-w64-x86_64-ncurses
(6.3-5 -> 6.3-6)
[2022-12-12T13:00:20+0100] [ALPM] upgraded mingw-w64-x86_64-openssl
(1.1.1.q-1 -> 1.1.1.s-1)
[2022-12-12T13:00:21+0100] [ALPM] upgraded mingw-w64-x86_64-readline
(8.1.002-2 -> 8.2.001-5)
[2022-12-12T13:00:29+0100] [ALPM] upgraded mingw-w64-x86_64-sqlite3
(3.39.2-1 -> 3.40.0-1)
[2022-12-12T13:00:40+0100] [ALPM] upgraded mingw-w64-x86_64-xz (5.2.7-1
-> 5.2.9-1)
[2022-12-12T13:00:58+0100] [ALPM] upgraded mingw-w64-x86_64-tzdata
(2022b-1 -> 2022g-1)
[2022-12-12T13:03:19+0100] [ALPM] upgraded mingw-w64-x86_64-python
(3.10.8-1 -> 3.10.9-1)
[2022-12-12T13:03:41+0100] [ALPM] upgraded mingw-w64-x86_64-glib2
(2.74.0-1 -> 2.74.3-1)
[2022-12-12T13:03:43+0100] [ALPM] upgraded mingw-w64-x86_64-libpng
(1.6.38-1 -> 1.6.39-1)
[2022-12-12T13:03:45+0100] [ALPM] upgraded mingw-w64-x86_64-libdeflate
(1.14-1 -> 1.15-1)
[2022-12-12T13:04:13+0100] [ALPM] upgraded mingw-w64-x86_64-gdk-pixbuf2
(2.42.9-1 -> 2.42.10-1)
[2022-12-12T13:04:14+0100] [ALPM] upgraded mingw-w64-x86_64-harfbuzz
(5.3.0-1 -> 5.3.1-2)
[2022-12-12T13:04:15+0100] [ALPM] upgraded mingw-w64-x86_64-fontconfig
(2.14.0-1 -> 2.14.1-1)
[2022-12-12T13:04:40+0100] [ALPM-SCRIPTLET] updating font cache... done.
[2022-12-12T13:04:41+0100] [ALPM] upgraded mingw-w64-x86_64-pixman
(0.40.0-2 -> 0.42.2-1)
[2022-12-12T13:04:41+0100] [ALPM] upgraded mingw-w64-x86_64-pango
(1.50.11-1 -> 1.50.12-1)
[2022-12-12T13:04:42+0100] [ALPM] upgraded mingw-w64-x86_64-libxml2
(2.10.2-4 -> 2.10.3-1)
[2022-12-12T13:04:43+0100] [ALPM] upgraded mingw-w64-x86_64-librsvg
(2.54.4-2 -> 2.55.1-2)
[2022-12-12T13:05:14+0100] [ALPM] upgraded
mingw-w64-x86_64-adwaita-icon-theme (42.0-1 -> 43-1)
[2022-12-12T13:06:18+0100] [ALPM] upgraded
mingw-w64-x86_64-arm-none-eabi-gcc (10.1.0-2 -> 12.2.0-1)
[2022-12-12T13:06:38+0100] [ALPM] upgraded mingw-w64-x86_64-avr-binutils
(2.38-3 -> 2.39-1)
[2022-12-12T13:07:06+0100] [ALPM] upgraded mingw-w64-x86_64-avr-gcc
(8.5.0-1 -> 12.2.0-1)
[2022-12-12T13:08:44+0100] [ALPM] upgraded mingw-w64-x86_64-llvm
(15.0.2-1 -> 15.0.5-1)
[2022-12-12T13:09:17+0100] [ALPM] upgraded mingw-w64-x86_64-headers-git
(10.0.0.r113.g57fd0b77a-1 -> 10.0.0.r157.gd295924f0-1)
[2022-12-12T13:09:41+0100] [ALPM] upgraded mingw-w64-x86_64-crt-git
(10.0.0.r113.g57fd0b77a-1 -> 10.0.0.r157.gd295924f0-1)
[2022-12-12T13:09:42+0100] [ALPM] upgraded
mingw-w64-x86_64-winpthreads-git (10.0.0.r113.g57fd0b77a-1 ->
10.0.0.r157.gd295924f0-1)
[2022-12-12T13:10:02+0100] [ALPM] upgraded mingw-w64-x86_64-gcc
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:10:31+0100] [ALPM] upgraded mingw-w64-x86_64-clang
(15.0.2-1 -> 15.0.5-1)
[2022-12-12T13:10:31+0100] [ALPM] upgraded mingw-w64-x86_64-nghttp2
(1.48.0-1 -> 1.51.0-1)
[2022-12-12T13:10:47+0100] [ALPM] upgraded mingw-w64-x86_64-curl
(7.85.0-1 -> 7.86.0-5)
[2022-12-12T13:10:53+0100] [ALPM] upgraded mingw-w64-x86_64-icu (71.1-1
-> 72.1-1)
[2022-12-12T13:10:54+0100] [ALPM] upgraded mingw-w64-x86_64-nuspell
(5.1.2-1 -> 5.1.2-2)
[2022-12-12T13:10:55+0100] [ALPM] upgraded mingw-w64-x86_64-enchant
(2.3.3-2 -> 2.3.3-3)
[2022-12-12T13:10:55+0100] [ALPM] upgraded mingw-w64-x86_64-fftw
(3.3.10-3 -> 3.3.10-4)
[2022-12-12T13:10:56+0100] [ALPM] upgraded mingw-w64-x86_64-freeglut
(3.4.0-1 -> 3.4.0-2)
[2022-12-12T13:13:15+0100] [ALPM] upgraded mingw-w64-x86_64-gcc-ada
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:13:15+0100] [ALPM] upgraded
mingw-w64-x86_64-gcc-libgfortran (12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:13:17+0100] [ALPM] upgraded mingw-w64-x86_64-gcc-fortran
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:13:24+0100] [ALPM] upgraded mingw-w64-x86_64-gcc-objc
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:13:27+0100] [ALPM] upgraded mingw-w64-x86_64-gdb (12.1-4
-> 12.1-5)
[2022-12-12T13:13:28+0100] [ALPM] upgraded
mingw-w64-x86_64-gdb-multiarch (12.1-4 -> 12.1-5)
[2022-12-12T13:13:37+0100] [ALPM] upgraded mingw-w64-x86_64-gnutls
(3.7.7-2 -> 3.7.8-1)
[2022-12-12T13:13:37+0100] [ALPM] upgraded
mingw-w64-x86_64-gtk-update-icon-cache (3.24.34+156+g812b3930d0-1 ->
3.24.35-1)
[2022-12-12T13:13:50+0100] [ALPM] upgraded mingw-w64-x86_64-gtk3
(3.24.34+156+g812b3930d0-1 -> 3.24.35-1)
[2022-12-12T13:14:02+0100] [ALPM] upgraded mingw-w64-x86_64-jasper
(3.0.6-2 -> 4.0.0-1)
[2022-12-12T13:14:02+0100] [ALPM] upgraded mingw-w64-x86_64-lcms2
(2.13.1-2 -> 2.14-1)
[2022-12-12T13:14:03+0100] [ALPM] upgraded mingw-w64-x86_64-libde265
(1.0.8-3 -> 1.0.9-1)
[2022-12-12T13:14:03+0100] [ALPM] upgraded mingw-w64-x86_64-rav1e
(0.5.1-3 -> 0.6.1-1)
[2022-12-12T13:14:03+0100] [ALPM] installed mingw-w64-x86_64-svt-av1
(1.4.0-1)
[2022-12-12T13:14:04+0100] [ALPM] upgraded mingw-w64-x86_64-libheif
(1.13.0-2 -> 1.14.0-1)
[2022-12-12T13:14:19+0100] [ALPM] upgraded mingw-w64-x86_64-imagemagick
(7.1.0.50-1 -> 7.1.0.52-2)
[2022-12-12T13:14:19+0100] [ALPM] upgraded mingw-w64-x86_64-libgccjit
(12.2.0-4 -> 12.2.0-6)
[2022-12-12T13:14:19+0100] [ALPM] upgraded
mingw-w64-x86_64-libmangle-git (10.0.0.r113.g57fd0b77a-1 ->
10.0.0.r157.gd295924f0-1)
[2022-12-12T13:14:21+0100] [ALPM] upgraded mingw-w64-x86_64-libxslt
(1.1.37-1 -> 1.1.37-2)
[2022-12-12T13:14:21+0100] [ALPM] upgraded mingw-w64-x86_64-make (4.3-1
-> 4.4-2)
[2022-12-12T13:14:30+0100] [ALPM] upgraded
mingw-w64-x86_64-mupdf-libmupdf (1.20.3-1 -> 1.21.0-1)
[2022-12-12T13:14:30+0100] [ALPM] upgraded mingw-w64-x86_64-pdcurses
(4.3.4-1 -> 4.3.5-1)
[2022-12-12T13:14:33+0100] [ALPM] upgraded mingw-w64-x86_64-poppler
(22.07.0-2 -> 22.12.0-1)
[2022-12-12T13:14:47+0100] [ALPM] upgraded
mingw-w64-x86_64-python-setuptools (65.5.0-1 -> 65.6.3-1)
[2022-12-12T13:15:19+0100] [ALPM] upgraded
mingw-w64-x86_64-python-nuitka (1.1.5-1 -> 1.2.6-1)
[2022-12-12T13:15:45+0100] [ALPM] upgraded mingw-w64-x86_64-python-pip
(22.2.2-1 -> 22.3.1-1)
[2022-12-12T13:16:21+0100] [ALPM] upgraded mingw-w64-x86_64-ruby
(3.1.2-3 -> 3.1.3-1)
[2022-12-12T13:16:21+0100] [ALPM] upgraded mingw-w64-x86_64-tools-git
(10.0.0.r113.g57fd0b77a-1 -> 10.0.0.r157.gd295924f0-1)
[2022-12-12T13:16:22+0100] [ALPM] upgraded
mingw-w64-x86_64-winstorecompat-git (10.0.0.r113.g57fd0b77a-1 ->
10.0.0.r157.gd295924f0-1)
[2022-12-12T13:16:34+0100] [ALPM] upgraded mingw-w64-x86_64-xapian-core
(1~1.4.20-2 -> 1~1.4.21-1)
[2022-12-12T13:16:34+0100] [ALPM] upgraded mingw-w64-x86_64-zeromq
(4.3.4-1 -> 4.3.4-2)
[2022-12-12T13:16:34+0100] [ALPM] upgraded mpc (1.2.1-1 -> 1.3.0-1)
[2022-12-12T13:16:34+0100] [ALPM] upgraded msys2-keyring (1~20220623-1
-> 1~20221024-1)
[2022-12-12T13:16:36+0100] [ALPM-SCRIPTLET] ==> Appending keys from
msys2.gpg...
[2022-12-12T13:16:38+0100] [ALPM-SCRIPTLET] ==> Updating trust database...
[2022-12-12T13:16:38+0100] [ALPM-SCRIPTLET] gpg: next trustdb check due
at 2023-04-22
[2022-12-12T13:16:41+0100] [ALPM] upgraded mutt (2.1.4-1 -> 2.2.9-1)
[2022-12-12T13:16:43+0100] [ALPM] upgraded openssl-devel (1.1.1.q-1 ->
1.1.1.s-1)
[2022-12-12T13:16:46+0100] [ALPM] upgraded xz (5.2.7-1 -> 5.2.9-1)
[2022-12-12T13:16:46+0100] [ALPM] upgraded pacman-contrib (1.7.1-1 ->
1.8.0-1)
[2022-12-12T13:16:46+0100] [ALPM] upgraded patch (2.7.6-1 -> 2.7.6-2)
[2022-12-12T13:16:47+0100] [ALPM] upgraded patchutils (0.4.2-2 -> 0.4.2-3)
[2022-12-12T13:16:49+0100] [ALPM] upgraded pcre (8.45-1 -> 8.45-3)
[2022-12-12T13:16:52+0100] [ALPM] upgraded pcre-devel (8.45-1 -> 8.45-3)
[2022-12-12T13:16:54+0100] [ALPM] upgraded perl-YAML-Syck (1.34-1 -> 1.34-2)
[2022-12-12T13:16:54+0100] [ALPM] upgraded pkgconf (1.8.0-1 -> 1.8.0-2)
[2022-12-12T13:16:55+0100] [ALPM] upgraded python-lxml (4.9.0-2 -> 4.9.1-1)
[2022-12-12T13:17:03+0100] [ALPM] upgraded python-setuptools (63.2.0-1
-> 65.6.3-1)
[2022-12-12T13:17:55+0100] [ALPM] upgraded ruby (2.7.6-1 -> 3.1.3-1)
[2022-12-12T13:18:02+0100] [ALPM] upgraded texinfo (6.8-4 -> 7.0.1-1)
[2022-12-12T13:18:02+0100] [ALPM] upgraded texinfo-tex (6.8-4 -> 7.0.1-1)
[2022-12-12T13:18:03+0100] [ALPM] upgraded tig (2.5.6-1 -> 2.5.7-1)
[2022-12-12T13:18:27+0100] [ALPM] upgraded tzcode (2022d-1 -> 2022g-1)
[2022-12-12T13:18:27+0100] [ALPM] upgraded unrar (6.1.4-1 -> 6.2.2-1)
[2022-12-12T13:18:35+0100] [ALPM] upgraded util-linux (2.35.2-1 -> 2.35.2-3)
[2022-12-12T13:18:41+0100] [ALPM] upgraded wget (1.21.3-1 -> 1.21.3-2)
[2022-12-12T13:18:41+0100] [ALPM] upgraded xmlto (0.0.28-3 -> 0.0.28-4)
[2022-12-12T13:18:43+0100] [ALPM] upgraded yelp-xsl (42.0-1 -> 42.1-1)
[2022-12-12T13:18:43+0100] [ALPM] upgraded yelp-tools (42.0-1 -> 42.1-1)
[2022-12-12T13:19:00+0100] [ALPM] upgraded zsh (5.9-1 -> 5.9-2)
[2022-12-12T13:19:00+0100] [ALPM] transaction completed
[2022-12-12T13:19:01+0100] [ALPM] running
'mingw-w64-x86_64-fontconfig.hook'...
[2022-12-12T13:19:02+0100] [ALPM] running
'mingw-w64-x86_64-gdk-pixbuf-query-loaders.hook'...
[2022-12-12T13:19:05+0100] [ALPM] running
'mingw-w64-x86_64-glib-compile-schemas.hook'...
[2022-12-12T13:19:06+0100] [ALPM] running
'mingw-w64-x86_64-gtk-update-icon-cache.hook'...
[2022-12-12T13:19:09+0100] [ALPM] running
'mingw-w64-x86_64-update-mime-database.hook'...
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET]
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] Note that
'C:/msys64/mingw64/share' is not in the search path
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] set by the XDG_DATA_HOME and
XDG_DATA_DIRS
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] environment variables, so
applications may not
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] be able to find it until you
set them. The
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] directories currently
searched are:
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET]
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] -
C:\msys64\home\User\.local\share
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] - /usr/local/share/
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET] - /usr/share/
[2022-12-12T13:19:25+0100] [ALPM-SCRIPTLET]
[2022-12-12T13:19:25+0100] [ALPM] running 'texinfo-install.hook'...
[2022-12-12T14:23:15+0100] [PACMAN] Running 'pacman -Syuu'
[2022-12-12T14:23:15+0100] [PACMAN] synchronizing package lists
[2022-12-12T14:23:31+0100] [PACMAN] starting core system upgrade
[2022-12-12T14:23:32+0100] [PACMAN] starting full system upgrade


> 
>> Here is the full build output:
> 
> I see nothing out of ordinary here, except the final failure.
> 
> What happens if you run this command:
> 
>  ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/
> 
> manually, from the MSYS Bash prompt in the src directory -- does it
> succeed?

User@UserPC MINGW64 ~/src/emacs/src
$ ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest
/mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/

User@UserPC MINGW64 ~/src/emacs/src
$ echo $?
127

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> Date: Mon, 12 Dec 2022 17:03:32 +0100
> Cc: emacs-devel@gnu.org
> From: Loreno Heer <helohe@bluewin.ch>
> 
> > Which parts of MinGW got updated?  Did Make get updated? or Bash?
> 
> [2022-12-12T12:35:19+0100] [PACMAN] Running 'pacman -Syuu'
> [2022-12-12T12:35:19+0100] [PACMAN] synchronizing package lists
> [2022-12-12T12:35:36+0100] [PACMAN] starting core system upgrade
> [2022-12-12T12:37:14+0100] [ALPM] transaction started
> [2022-12-12T12:37:16+0100] [ALPM] upgraded bash (5.1.016-1 -> 5.2.009-1)
[...]

So basically, lots of stuff was updated including Bash.  Who knows
what that could cause?

Are you able to build the source tarball of Emacs 28.2?

Do you have an anti-virus installed? if so, can you turn it off, or
temporarily disable it, and try again?
> $ ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest
> /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/
> 
> User@UserPC MINGW64 ~/src/emacs/src
> $ echo $?
> 127

So it isn't Make, probably.  But it still could be Bash, or some of
the libraries that Emacs links in.

Re: MinGW build on master fails with Error 127

[Loreno Heer]

On 12.12.2022 17:11, Eli Zaretskii wrote:
>> Date: Mon, 12 Dec 2022 17:03:32 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>>> Which parts of MinGW got updated?  Did Make get updated? or Bash?
>>
>> [2022-12-12T12:35:19+0100] [PACMAN] Running 'pacman -Syuu'
>> [2022-12-12T12:35:19+0100] [PACMAN] synchronizing package lists
>> [2022-12-12T12:35:36+0100] [PACMAN] starting core system upgrade
>> [2022-12-12T12:37:14+0100] [ALPM] transaction started
>> [2022-12-12T12:37:16+0100] [ALPM] upgraded bash (5.1.016-1 -> 5.2.009-1)
> [...]
> 
> So basically, lots of stuff was updated including Bash.  Who knows
> what that could cause?
> 
> Are you able to build the source tarball of Emacs 28.2?

I just tried now, this gives the same error. So most likely something
changed in mingw that breaks the build.
I will see if any update in the next day or so fixes it again.

> 
> Do you have an anti-virus installed? if so, can you turn it off, or
> temporarily disable it, and try again?

I don't use any.

>> $ ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest
>> /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/
>>
>> User@UserPC MINGW64 ~/src/emacs/src
>> $ echo $?
>> 127
> 
> So it isn't Make, probably.  But it still could be Bash, or some of
> the libraries that Emacs links in.

Re: MinGW build on master fails with Error 127

[Loreno Heer]

I got it to build by manually setting

#define _WIN32_WINNT 0x0601

in the emacs config.h file.
Not sure why but this variable seems to have the (wrong) value of 0x0603
on my system (Windows 7 ESR). I don't know if this is a variable that
emacs build defines somewhere or the msys build system.

On 12.12.2022 17:11, Eli Zaretskii wrote:
>> Date: Mon, 12 Dec 2022 17:03:32 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>>> Which parts of MinGW got updated?  Did Make get updated? or Bash?
>>
>> [2022-12-12T12:35:19+0100] [PACMAN] Running 'pacman -Syuu'
>> [2022-12-12T12:35:19+0100] [PACMAN] synchronizing package lists
>> [2022-12-12T12:35:36+0100] [PACMAN] starting core system upgrade
>> [2022-12-12T12:37:14+0100] [ALPM] transaction started
>> [2022-12-12T12:37:16+0100] [ALPM] upgraded bash (5.1.016-1 -> 5.2.009-1)
> [...]
> 
> So basically, lots of stuff was updated including Bash.  Who knows
> what that could cause?
> 
> Are you able to build the source tarball of Emacs 28.2?
> 
> Do you have an anti-virus installed? if so, can you turn it off, or
> temporarily disable it, and try again?
>> $ ./temacs --batch -l loadup --temacs=pbootstrap --bin-dest
>> /mingw64/bin/ --eln-dest /mingw64/lib/emacs/30.0.50/
>>
>> User@UserPC MINGW64 ~/src/emacs/src
>> $ echo $?
>> 127
> 
> So it isn't Make, probably.  But it still could be Bash, or some of
> the libraries that Emacs links in.
> 
> 

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> Date: Fri, 23 Dec 2022 22:45:22 +0100
> Cc: emacs-devel@gnu.org
> From: Loreno Heer <helohe@bluewin.ch>
> 
> I got it to build by manually setting
> 
> #define _WIN32_WINNT 0x0601
> 
> in the emacs config.h file.
> Not sure why but this variable seems to have the (wrong) value of 0x0603
> on my system (Windows 7 ESR). I don't know if this is a variable that
> emacs build defines somewhere or the msys build system.

Emacs doesn't set _WIN32_WINNT to this value anywhere.  (And anyway, I
don't see how setting it to a higher value could do any harm, when
0x0601 does work.)

So please take this up with the MinGW64/MSYS2 developers, because it
sounds like some problem with their system headers.  I don't see any
evidence here that there's something wrong in Emacs which causes this
problem.  Especially since it started happening lately, and happens
with older Emacs versions as well, where no changes have been done.

Re: MinGW build on master fails with Error 127

[Loreno Heer]

I did and if I understand it correctly they basically say that they did
some change but it is now up to emacs to change the build behavior:

https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364532147

On 24.12.2022 07:36, Eli Zaretskii wrote:
>> Date: Fri, 23 Dec 2022 22:45:22 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>> I got it to build by manually setting
>>
>> #define _WIN32_WINNT 0x0601
>>
>> in the emacs config.h file.
>> Not sure why but this variable seems to have the (wrong) value of 0x0603
>> on my system (Windows 7 ESR). I don't know if this is a variable that
>> emacs build defines somewhere or the msys build system.
> 
> Emacs doesn't set _WIN32_WINNT to this value anywhere.  (And anyway, I
> don't see how setting it to a higher value could do any harm, when
> 0x0601 does work.)
> 
> So please take this up with the MinGW64/MSYS2 developers, because it
> sounds like some problem with their system headers.  I don't see any
> evidence here that there's something wrong in Emacs which causes this
> problem.  Especially since it started happening lately, and happens
> with older Emacs versions as well, where no changes have been done.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> Date: Sat, 24 Dec 2022 15:18:02 +0100
> Cc: emacs-devel@gnu.org
> From: Loreno Heer <helohe@bluewin.ch>
> 
> I did and if I understand it correctly they basically say that they did
> some change but it is now up to emacs to change the build behavior:
> 
> https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364532147

Are you building Emacs on Windows 7?  If yes, I understand what they
are saying: that MinGW64 no longer supports Windows 7.

If you build on a later version of Windows, then I don't understand
what they are saying:

  As examples mentioned on #14452 illustrate, a package can support
  Win7 fine but if we say to its build system that we target >Win7 the
  resulting binary may be incompatible with Win7. This means in
  practice that Emacs (or any other software) can't rely on using our
  packages as runtime dependencies for supporting Win7.

Emacs will support MS-Windows versions as old as Windows 9X, as long
as the MinGW headers and runtime support those versions.  If your
MinGW supports only Windows versions newer than some version N, then
Emacs cannot magically overcome this limitation, and will also support
only versions of Windows newer than N.

Re: MinGW build on master fails with Error 127

[Loreno Heer]

On 24.12.2022 15:43, Eli Zaretskii wrote:
>> Date: Sat, 24 Dec 2022 15:18:02 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>> I did and if I understand it correctly they basically say that they did
>> some change but it is now up to emacs to change the build behavior:
>>
>> https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364532147
> 
> Are you building Emacs on Windows 7?  If yes, I understand what they
> are saying: that MinGW64 no longer supports Windows 7.

Yes I am building on Win 7 ESR. But it looks like I have to switch to
linux soon because everyone drops support for it.

I think in theory though their build system still supports win 7 or
older just fine. As long as I set that variable everything builds and
runs just fine.
> 
> If you build on a later version of Windows, then I don't understand
> what they are saying:
> 
>   As examples mentioned on #14452 illustrate, a package can support
>   Win7 fine but if we say to its build system that we target >Win7 the
>   resulting binary may be incompatible with Win7. This means in
>   practice that Emacs (or any other software) can't rely on using our
>   packages as runtime dependencies for supporting Win7.
> 
> Emacs will support MS-Windows versions as old as Windows 9X, as long
> as the MinGW headers and runtime support those versions.  If your
> MinGW supports only Windows versions newer than some version N, then
> Emacs cannot magically overcome this limitation, and will also support
> only versions of Windows newer than N.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> Date: Sat, 24 Dec 2022 16:11:47 +0100
> Cc: emacs-devel@gnu.org
> From: Loreno Heer <helohe@bluewin.ch>
> 
> > Are you building Emacs on Windows 7?  If yes, I understand what they
> > are saying: that MinGW64 no longer supports Windows 7.
> 
> Yes I am building on Win 7 ESR. But it looks like I have to switch to
> linux soon because everyone drops support for it.
> 
> I think in theory though their build system still supports win 7 or
> older just fine. As long as I set that variable everything builds and
> runs just fine.

In general, when the runtime drops support for Windows 7, you cannot
reliably run binaries produced with that runtime on that system.  It
could be sheer luck that you get away during the build process, and
even if you do get away, the produced binary could fail in some weird
ways afterwards.

Re: MinGW build on master fails with Error 127

[Loreno Heer]

On 24.12.2022 16:44, Eli Zaretskii wrote:
>> Date: Sat, 24 Dec 2022 16:11:47 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>>
>>> Are you building Emacs on Windows 7?  If yes, I understand what they
>>> are saying: that MinGW64 no longer supports Windows 7.
>>
>> Yes I am building on Win 7 ESR. But it looks like I have to switch to
>> linux soon because everyone drops support for it.
>>
>> I think in theory though their build system still supports win 7 or
>> older just fine. As long as I set that variable everything builds and
>> runs just fine.
> 
> In general, when the runtime drops support for Windows 7, you cannot
> reliably run binaries produced with that runtime on that system.  It
> could be sheer luck that you get away during the build process, and
> even if you do get away, the produced binary could fail in some weird
> ways afterwards.

That is a pity, but thanks for all the help and pointing this out.
I planned to migrate to linux at some point next year anyway. Mostly
just my music player and some other things (firmware updates for RME
hardware) keep forcing me to use windows. But still was hoping to have
some more time to do so.
> 
> 

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 24 Dec 2022 15:18:02 +0100
>> Cc: emacs-devel@gnu.org
>> From: Loreno Heer <helohe@bluewin.ch>
>> 
>> I did and if I understand it correctly they basically say that they did
>> some change but it is now up to emacs to change the build behavior:
>> 
>> https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364532147
>
> Are you building Emacs on Windows 7?  If yes, I understand what they
> are saying: that MinGW64 no longer supports Windows 7.

Please note that MinGW-w64 and MSYS2 (which includes MINGW-packages) are
different projects. MSYS2 builds, packages and distributes MinGW-w64.
MSYS2 decided to bump _WIN32_WINNT in our build scripts, which has
implications for Emacs (see below) but that's independent of what
MinGW-w64 actually, officially supports.

> If you build on a later version of Windows, then I don't understand
> what they are saying:
>
>   As examples mentioned on #14452 illustrate, a package can support
>   Win7 fine but if we say to its build system that we target >Win7 the
>   resulting binary may be incompatible with Win7. This means in
>   practice that Emacs (or any other software) can't rely on using our
>   packages as runtime dependencies for supporting Win7.

I wrote the text you quote above, so I'll explain.

Some packages (including the MinGW-w64 runtime) implement compile-time
conditionals for preferring certain APIs over others depending on the
target OS version. So once we start distributing binary packages built
with the bumped _WIN32_WINNT value, some Emacs dependencies may fail to
run on Windows 7.

Which is basically what you say here:

> Emacs will support MS-Windows versions as old as Windows 9X, as long
> as the MinGW headers and runtime support those versions.  If your
> MinGW supports only Windows versions newer than some version N, then
> Emacs cannot magically overcome this limitation, and will also support
> only versions of Windows newer than N.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Loreno Heer <helohe@bluewin.ch>,  emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 16:31:57 +0100
> 
> Please note that MinGW-w64 and MSYS2 (which includes MINGW-packages) are
> different projects. MSYS2 builds, packages and distributes MinGW-w64.
> MSYS2 decided to bump _WIN32_WINNT in our build scripts, which has
> implications for Emacs (see below) but that's independent of what
> MinGW-w64 actually, officially supports.

So what are the details?  Which versions of Windows does MSYS2
support, and which ones does MinGW64 support?  And if MinGW64 is about
to drop Windows versions older than 8.1 soon, when will that happen?

I'm asking because I want to update our documentation with this
information, to avoid other users being surprised by these subtle
issues.

Thanks.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Please note that MinGW-w64 and MSYS2 (which includes MINGW-packages) are
>> different projects. MSYS2 builds, packages and distributes MinGW-w64.
>> MSYS2 decided to bump _WIN32_WINNT in our build scripts, which has
>> implications for Emacs (see below) but that's independent of what
>> MinGW-w64 actually, officially supports.
>
> So what are the details?  Which versions of Windows does MSYS2
> support, 

Since about 1 week ago, the minimum requirement is Windows 8.1. Hardware
requirements were also recently upgraded. A CPU from 2007 onwards should
be fine:

https://www.msys2.org/news/#2022-10-18-new-minimum-hardware-requirements-cpus-from-20067

> and which ones does MinGW64 support?

AFAIK nothing changed for MinGW-w64. I don't know about their planning,
though.

> And if MinGW64 is about
> to drop Windows versions older than 8.1 soon, when will that happen?

See above. Please note that Mingw-w64 alone is useless, you need to
configure your toolchain to use it. MSYS2 provides toolchains ready to
use. Plus, requirements such as libwinpthreads, which are also
maintained by Mingw-w64, might have their own requirements (AFAIK
nothing changed yet.)

> I'm asking because I want to update our documentation with this
> information, to avoid other users being surprised by these subtle
> issues.

I would say that for using an MSYS2-based build of Emacs you need
Windows 8.1 at the least. A more future-proof statement is to recommend
looking up that information on the MSYS2 web page.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: helohe@bluewin.ch,  emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 17:14:56 +0100
> 
> > I'm asking because I want to update our documentation with this
> > information, to avoid other users being surprised by these subtle
> > issues.
> 
> I would say that for using an MSYS2-based build of Emacs you need
> Windows 8.1 at the least. A more future-proof statement is to recommend
> looking up that information on the MSYS2 web page.

Thanks.

And as long as I have your attention: what about the switch to UCRT64?
Does Emacs need something in its Makefile's to specify linking against
MSVCRT, even though UCRT64 is the default?  The information at

  https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64

doesn't provide any details about that.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> And as long as I have your attention: what about the switch to UCRT64?
> Does Emacs need something in its Makefile's to specify linking against
> MSVCRT, even though UCRT64 is the default?  The information at
>
>   https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64
>
> doesn't provide any details about that.

See

https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs

There is a patch specific for UCRT support. It's quite simple although
the workaround for close_stream doesn't inspire confidence, hints that
there might be subtle differences on the behavior of C runtime
functions.

This is the relevant commit message:

commit 01be90ce74e3b69e7b03ab886d5f4ac59da0f646
Author: Christoph Reiter
Date:   Thu Jun 23 21:34:12 2022 +0200

    emacs: some hacky patches to make it work on ucrt64
    
    for both stdout and stderr fclose fail during atexit as if they
    were already closed. the function in theory has a workaround for that
    in that it will continue if errno is EBADF, but fclose doesn't set that
    on Windows.
    
    This shows at least what is missing/broken if upstream wants to have a look.


Of course the Emacs UCRT build lacks the real-world testing that the
Mingw-w64 one has, so we need to wait for bug reports.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

[Resending because messages posted through gmane take several hours to
appear on the mailing list. Sorry for the duplicate.]

Eli Zaretskii <eliz@gnu.org> writes:

> And as long as I have your attention: what about the switch to UCRT64?
> Does Emacs need something in its Makefile's to specify linking against
> MSVCRT, even though UCRT64 is the default?  The information at
>
>   https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64
>
> doesn't provide any details about that.

See

https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs

There is a patch specific for UCRT support. It's quite simple although
the workaround for close_stream doesn't inspire confidence, hints that
there might be subtle differences on the behavior of C runtime
functions.

This is the relevant commit message:

commit 01be90ce74e3b69e7b03ab886d5f4ac59da0f646
Author: Christoph Reiter
Date:   Thu Jun 23 21:34:12 2022 +0200

    emacs: some hacky patches to make it work on ucrt64
    
    for both stdout and stderr fclose fail during atexit as if they
    were already closed. the function in theory has a workaround for that
    in that it will continue if errno is EBADF, but fclose doesn't set that
    on Windows.
    
    This shows at least what is missing/broken if upstream wants to have a look.


Of course the Emacs UCRT build lacks the real-world testing that the
Mingw-w64 one has, so we need to wait for bug reports.

BTW, there is a patch for building with Clang on Windows.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 18:08:10 +0100
> 
> > And as long as I have your attention: what about the switch to UCRT64?
> > Does Emacs need something in its Makefile's to specify linking against
> > MSVCRT, even though UCRT64 is the default?  The information at
> >
> >   https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64
> >
> > doesn't provide any details about that.
> 
> See
> 
> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs

There's nothing there regarding the runtime against which Emacs is
being linked.  How does GCC/ld know which runtime to link against?  Up
until now GCC would call the linker with the -lmsvcrt switch, so does
it now use some other switch?  And what can users do to force MinGW64
to link against MSVCRT, if they so wish?

> There is a patch specific for UCRT support. It's quite simple although
> the workaround for close_stream doesn't inspire confidence, hints that
> there might be subtle differences on the behavior of C runtime
> functions.

It's a beginning of a very long journey, to learn about UCRT what
we've invested decades to learn about MSVCRT.  And the patch indeed is
not really acceptable, as it disables useful behavior without a
reasonable explanation.

Are the sources of UCRT available somewhere (as MSVCRT sources were)?

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > And as long as I have your attention: what about the switch to UCRT64?
>> > Does Emacs need something in its Makefile's to specify linking against
>> > MSVCRT, even though UCRT64 is the default?  The information at
>> >
>> >   https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64
>> >
>> > doesn't provide any details about that.
>> 
>> See
>> 
>> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs
>
> There's nothing there regarding the runtime against which Emacs is
> being linked.  How does GCC/ld know which runtime to link against?  Up
> until now GCC would call the linker with the -lmsvcrt switch, so does
> it now use some other switch?

MSYS2 distributes multiple toolset/c-runtime combinations. Toolsets can
be GNU (gcc, binutils, etc) or Clang, and c-runtime can be either
mingw-w64 or UCRT. For a given combination the toolset is configured to
work with a c-runtime, so it already knows what it needs to do the right
thing. I guess it is possible to override the configuration of a toolset
so to use a different c-runtime, but that's not something that MSYS2
encourage.

> And what can users do to force MinGW64 to link against MSVCRT, if they
> so wish?

The MSYS2 distribution named "MINGW64" already links to MSVCRT, as
always did, and that will not change. Is the UCRT64 distribution the one
that provides a gcc/binutils/everything-else that links to UCRT.

>> There is a patch specific for UCRT support. It's quite simple although
>> the workaround for close_stream doesn't inspire confidence, hints that
>> there might be subtle differences on the behavior of C runtime
>> functions.
>
> It's a beginning of a very long journey, to learn about UCRT what
> we've invested decades to learn about MSVCRT.

AFAIK UCRT should work just fine (TM) as it is not an entirely new C
Runtime, but a vastly updated version of MSVCRT with a new model of
deployment for more robust versioning that allows incremental additions.
I'm sure there are subtle differences and even some intended departure
from behaviors that are deemed undesirable, though.

My experience, both with my own projects and with the packages MSYS2
distributes, indicate that migrating to it is fairly painless, if
noticeable at all.

> And the patch indeed is not really acceptable, as it disables useful
> behavior without a reasonable explanation.

The commit message says "fclose fail during atexit as if they were
already closed" but indeed it doesn't describe a user-visible problem. I
can ask for more details, if you are interested.

> Are the sources of UCRT available somewhere (as MSVCRT sources were)?

They are distributed with Visual Studio. They are missing from a
Community (the gratis version) install that I have around, but maybe I
didn't check the option for installing them.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 18:57:55 +0100
> 
> MSYS2 distributes multiple toolset/c-runtime combinations. Toolsets can
> be GNU (gcc, binutils, etc) or Clang, and c-runtime can be either
> mingw-w64 or UCRT. For a given combination the toolset is configured to
> work with a c-runtime, so it already knows what it needs to do the right
> thing. I guess it is possible to override the configuration of a toolset
> so to use a different c-runtime, but that's not something that MSYS2
> encourage.
> 
> > And what can users do to force MinGW64 to link against MSVCRT, if they
> > so wish?
> 
> The MSYS2 distribution named "MINGW64" already links to MSVCRT, as
> always did, and that will not change. Is the UCRT64 distribution the one
> that provides a gcc/binutils/everything-else that links to UCRT.

So if the user has the UCRT version installed, they will necessarily
link against UCRT64.

Does the wording in nt/INSTALL.W64 guide users to only one of these
two variants (and if so, to which one), or is it generic, and the user
will have to choose when they install MinGW?

> >> There is a patch specific for UCRT support. It's quite simple although
> >> the workaround for close_stream doesn't inspire confidence, hints that
> >> there might be subtle differences on the behavior of C runtime
> >> functions.
> >
> > It's a beginning of a very long journey, to learn about UCRT what
> > we've invested decades to learn about MSVCRT.
> 
> AFAIK UCRT should work just fine (TM) as it is not an entirely new C
> Runtime, but a vastly updated version of MSVCRT with a new model of
> deployment for more robust versioning that allows incremental additions.
> I'm sure there are subtle differences and even some intended departure
> from behaviors that are deemed undesirable, though.

Subtle differences do exist, as that patch demonstrates.

Whether it will be painless for Emacs depends on how much of the
sources of MSVCRT was inherited by UCRT.  There are some quirks in
MSVCRT that took us time to find out and accommodate for, and w32.c
mentions that in several places.

> My experience, both with my own projects and with the packages MSYS2
> distributes, indicate that migrating to it is fairly painless, if
> noticeable at all.

See above: Emacs is quite demanding in this regard, so I'm not as
optimistic as you are, having spent enough hours reading the MSVCRT
sources and documentation.

> > And the patch indeed is not really acceptable, as it disables useful
> > behavior without a reasonable explanation.
> 
> The commit message says "fclose fail during atexit as if they were
> already closed" but indeed it doesn't describe a user-visible problem. I
> can ask for more details, if you are interested.

I am.  And note that the MS documentation shows an example where an
atexit function calls printf, so the standard streams are not really
closed at that time.  Something else is at work here, probably.

> > Are the sources of UCRT available somewhere (as MSVCRT sources were)?
> 
> They are distributed with Visual Studio. They are missing from a
> Community (the gratis version) install that I have around, but maybe I
> didn't check the option for installing them.

IME, being able to examine the sources was invaluable in quickly
resolving some issues.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The MSYS2 distribution named "MINGW64" already links to MSVCRT, as
>> always did, and that will not change. Is the UCRT64 distribution the one
>> that provides a gcc/binutils/everything-else that links to UCRT.
>
> So if the user has the UCRT version installed, they will necessarily
> link against UCRT64.

The user can have all distributions installed, if he wishes. They live
in separate directories.

There is an emacs package for each distribution (for instance:
mingw-w64-x86_64-emacs for MSVCRT on x86_64, mingw-w64-i686-emacs for
MSVCRT on x86, both built with gcc, mingw-w64-clang-x86_64-emacs for
UCRT64 built with Clang, etc). Each of those packages installs on a
different directory hierarchy.

If the user opts for building his own Emacs, he must take care of
installing it along its dependencies or running it after adjusting PATH
to point to the directory where the binary dependencies are stored. For
instance, if he builds in a CLANG64 shell, the resulting binary will
depend on UCRT and the dlls located in the subdirectory /clang64/bin of
the MSYS2 install.

> Does the wording in nt/INSTALL.W64 guide users to only one of these
> two variants (and if so, to which one), or is it generic, and the user
> will have to choose when they install MinGW?

It definitively points to the MINGW64 variant (the traditional one that
uses MSVCRT *and* runs on x86_64) because it lists the packages with the
mingw-w64-x86_64- prefix.

A cursory look also shows some important problems with that document.
For instance, gives a link to download the MSYS2 installer instead of
directing the user to the MSYS2 project webpage (msys2.org). That link
is no longer valid.

In general, I don't know why we (Emacs) make the effort of providing so
much guidance for building under MSYS2 when no similar level of detail
is provided for Debian, Fedora, Cygwin, etc. Actually, building Emacs
under MSYS2 is almost the same as the other platforms.

>> The commit message says "fclose fail during atexit as if they were
>> already closed" but indeed it doesn't describe a user-visible problem. I
>> can ask for more details, if you are interested.
>
> I am.

Ok, I'll ask the patch author.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 19:56:51 +0100
> 
> > Does the wording in nt/INSTALL.W64 guide users to only one of these
> > two variants (and if so, to which one), or is it generic, and the user
> > will have to choose when they install MinGW?
> 
> It definitively points to the MINGW64 variant (the traditional one that
> uses MSVCRT *and* runs on x86_64) because it lists the packages with the
> mingw-w64-x86_64- prefix.

OK, that's good.

> A cursory look also shows some important problems with that document.
> For instance, gives a link to download the MSYS2 installer instead of
> directing the user to the MSYS2 project webpage (msys2.org). That link
> is no longer valid.

Fixes for stale and outdated URLs will be appreciated.

> In general, I don't know why we (Emacs) make the effort of providing so
> much guidance for building under MSYS2 when no similar level of detail
> is provided for Debian, Fedora, Cygwin, etc.

The Windows users typically need to do more to arrange for a working
build environment than users on Posix hosts.

> Actually, building Emacs under MSYS2 is almost the same as the other
> platforms.

Once you have a suitable build environment, yes.  But until you get
there, no.

> >> The commit message says "fclose fail during atexit as if they were
> >> already closed" but indeed it doesn't describe a user-visible problem. I
> >> can ask for more details, if you are interested.
> >
> > I am.
> 
> Ok, I'll ask the patch author.

My guess is that close_stream (which is a Gnulib module) does
something that fails with UCRT.  For example, it uses __fpending, and
AFAIR that's defined in Emacs for Windows using the MSVCRT internals
of the FILE object, so maybe it needs to be amended.

In general, I would suggest to step into close_stream and see what
exactly fails there.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Does the wording in nt/INSTALL.W64 guide users to only one of these
>> > two variants (and if so, to which one), or is it generic, and the user
>> > will have to choose when they install MinGW?
>> 
>> It definitively points to the MINGW64 variant (the traditional one that
>> uses MSVCRT *and* runs on x86_64) because it lists the packages with the
>> mingw-w64-x86_64- prefix.
>
> OK, that's good.
>
>> A cursory look also shows some important problems with that document.
>> For instance, gives a link to download the MSYS2 installer instead of
>> directing the user to the MSYS2 project webpage (msys2.org). That link
>> is no longer valid.
>
> Fixes for stale and outdated URLs will be appreciated.

I fixed the URLs and simplified the instructions a bit. Some problems
remain:

* There are references to past emacs versions.

* The instructions for getting Emacs' sources via git create a versioned
  emacs directory when in fact the user is checking out master.

* The instructions for building from the tarball are mixed with the
  instructions for building from git. They use different names for the
  root source directory and there are expressions that might confuse the
  unexperienced user (there is a mention to "development sources" where
  those are previously referred as "the Git repository.")

* The --prefix parameter passed to `configure' will cause Emacs to be
  installed in the source directory.

* libgccjit is missing on the list of dependencies.

* ...probably more...

>> In general, I don't know why we (Emacs) make the effort of providing so
>> much guidance for building under MSYS2 when no similar level of detail
>> is provided for Debian, Fedora, Cygwin, etc.
>
> The Windows users typically need to do more to arrange for a working
> build environment than users on Posix hosts.

By large, the worst part of building Emacs is to figure out the packages
you need to install. That's equally difficult for most GNU/Linux
distributions as for MSYS2.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Dec 2022 03:46:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Fixes for stale and outdated URLs will be appreciated.
> 
> I fixed the URLs and simplified the instructions a bit.

Thanks.  (Please in the future make sure to leave two spaces between
sentences.)

This part is unclear:

  ** Download and install MinGW-w64 and MSYS2

  Go to https://msys2.org and follow the instructions.  It is not
  necessary to install the packages suggested on those instructions.

What does the last sentence mean? which packages are unnecessary?
Some of them, all of them?

Also, it looks like msys2.org tells users to install the UCRT64
variety of MinGW, whereas you said earlier that INSTALL.W64 points to
the MSVCRT variety.  Should we say something about this in the
Download and Install sections?

> Some problems remain:
> 
> * There are references to past emacs versions.

I fixed that, but I honestly don't see how this is important.  They
are just examples.

> * The instructions for getting Emacs' sources via git create a versioned
>   emacs directory when in fact the user is checking out master.

Fixed.

> * The instructions for building from the tarball are mixed with the
>   instructions for building from git. They use different names for the
>   root source directory and there are expressions that might confuse the
>   unexperienced user (there is a mention to "development sources" where
>   those are previously referred as "the Git repository.")

Fixed.

> * The --prefix parameter passed to `configure' will cause Emacs to be
>   installed in the source directory.

Fixed

> * libgccjit is missing on the list of dependencies.

Please tell how to modify the pacman command to add libgccjit.

> * ...probably more...

Feel free to fix.  I don't use MinGW64, so I cannot do that myself.

> >> In general, I don't know why we (Emacs) make the effort of providing so
> >> much guidance for building under MSYS2 when no similar level of detail
> >> is provided for Debian, Fedora, Cygwin, etc.
> >
> > The Windows users typically need to do more to arrange for a working
> > build environment than users on Posix hosts.
> 
> By large, the worst part of building Emacs is to figure out the packages
> you need to install. That's equally difficult for most GNU/Linux
> distributions as for MSYS2.

If by "packages" you mean the optional libraries, I agree to a point.
But what I meant was the development and build environment, which
includes GCC/Binutils, MSYS with all the related tools, Git, etc.
This comes OOTB on Posix hosts, but not on Windows.  Most problems
people have building Emacs on Windows are due to their environment
being incomplete or misconfigured, especially since the tools are not
native Windows tools, and some need a certain state of mind that
Windows users might lack.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I fixed the URLs and simplified the instructions a bit.
>
> Thanks.  (Please in the future make sure to leave two spaces between
> sentences.)

Uh! Sorry.

> This part is unclear:
>
>   ** Download and install MinGW-w64 and MSYS2
>
>   Go to https://msys2.org and follow the instructions.  It is not
>   necessary to install the packages suggested on those instructions.
>
> What does the last sentence mean? which packages are unnecessary?
> Some of them, all of them?

The packages mentioned on msys2.org either are the "wrong" ones (UCRT64)
or are already listed on INSTALL.W64.

> Also, it looks like msys2.org tells users to install the UCRT64
> variety of MinGW,

Yes, UCRT64 is the variety recommended by the MSYS2 team since recently.

> whereas you said earlier that INSTALL.W64 points to
> the MSVCRT variety.  Should we say something about this in the
> Download and Install sections?

That's already solved as our instructions direct the user to the MINGW64
shell and the packages on our list are the mingw-w64-x86_64-* variety.

>> Some problems remain:
>> 
>> * There are references to past emacs versions.
>
> I fixed that, but I honestly don't see how this is important.  They
> are just examples.

The impression I got from that document is that the user will tend to
type commands verbatim.

>> * libgccjit is missing on the list of dependencies.
>
> Please tell how to modify the pacman command to add libgccjit.

Add the package mingw-w64-x86_64-libgccjit.

>> By large, the worst part of building Emacs is to figure out the packages
>> you need to install. That's equally difficult for most GNU/Linux
>> distributions as for MSYS2.
>
> If by "packages" you mean the optional libraries, I agree to a point.
> But what I meant was the development and build environment, which
> includes GCC/Binutils, MSYS with all the related tools, Git, etc.
> This comes OOTB on Posix hosts, but not on Windows.

Last time I installed Debian I had to explicitly install gcc, binutils,
git, make... Indeed, figuring out the library dependencies is the worst
part by far, but AFAIK many GNU/Linux nowadays do not install a
development toolchain by default.

Don't get me wrong, INSTALL.W64 is nice to have. But I'm puzzled by it
providing so much specific detail while for other platforms we don't
even have a list of library names, much less the package names they are
distributed on popular distributions.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 25 Dec 2022 15:25:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   ** Download and install MinGW-w64 and MSYS2
> >
> >   Go to https://msys2.org and follow the instructions.  It is not
> >   necessary to install the packages suggested on those instructions.
> >
> > What does the last sentence mean? which packages are unnecessary?
> > Some of them, all of them?
> 
> The packages mentioned on msys2.org either are the "wrong" ones (UCRT64)
> or are already listed on INSTALL.W64.

So you are saying they should "follow the instructions" up until and
including item 5, and thereafter proceed with what we say in "**
Download and install the necessary packages"?

> > Also, it looks like msys2.org tells users to install the UCRT64
> > variety of MinGW,
> 
> Yes, UCRT64 is the variety recommended by the MSYS2 team since recently.
> 
> > whereas you said earlier that INSTALL.W64 points to
> > the MSVCRT variety.  Should we say something about this in the
> > Download and Install sections?
> 
> That's already solved as our instructions direct the user to the MINGW64
> shell and the packages on our list are the mingw-w64-x86_64-* variety.
> 
> >> Some problems remain:
> >> 
> >> * There are references to past emacs versions.
> >
> > I fixed that, but I honestly don't see how this is important.  They
> > are just examples.
> 
> The impression I got from that document is that the user will tend to
> type commands verbatim.
> 
> >> * libgccjit is missing on the list of dependencies.
> >
> > Please tell how to modify the pacman command to add libgccjit.
> 
> Add the package mingw-w64-x86_64-libgccjit.

Got it, thanks.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The packages mentioned on msys2.org either are the "wrong" ones (UCRT64)
>> or are already listed on INSTALL.W64.
>
> So you are saying they should "follow the instructions" up until and
> including item 5, and thereafter proceed with what we say in "**
> Download and install the necessary packages"?

I'm saying that the packages listed on msys2.org are either unnecessary
or redundant, so that step can be skipped. And the next step there is
just "see, you have gcc installed."

If you intend to adapt the INSTALL.W64 instructions keep in mind that
the instructions on msys2.org can change anytime, so saying "follow the
instructions on msys2.org until step 5" is not advisable.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> The commit message says "fclose fail during atexit as if they were
>>> already closed" but indeed it doesn't describe a user-visible problem. I
>>> can ask for more details, if you are interested.
>>
>> I am.
>
> Ok, I'll ask the patch author.

This is his answer:

  Afair it showed an error at exit and exited != 0.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 20:19:24 +0100
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> >>> The commit message says "fclose fail during atexit as if they were
> >>> already closed" but indeed it doesn't describe a user-visible problem. I
> >>> can ask for more details, if you are interested.
> >>
> >> I am.
> >
> > Ok, I'll ask the patch author.
> 
> This is his answer:
> 
>   Afair it showed an error at exit and exited != 0.

Here's the source code of close_stream (after I removed the comments):

  int
  close_stream (FILE *stream)
  {
    const bool some_pending = (__fpending (stream) != 0);
    const bool prev_fail = (ferror (stream) != 0);
    const bool fclose_fail = (fclose (stream) != 0);

    if (prev_fail || (fclose_fail && (some_pending || errno != EBADF)))
      {
	if (! fclose_fail)
	  errno = 0;
	return EOF;
      }

    return 0;
  }

My questions are simple: which of the conditions for the error return
actually happened?  And what was the value of 'errno' (the code only
filters out EBADF)?

Re: MinGW build on master fails with Error 127

[Po Lu]

If Emacs is built with ucrt or Clang, will it still work on Windows 9X?

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> If Emacs is built with ucrt or Clang, will it still work on Windows
> 9X?

I don't think so, no, as UCRT requires Windows Vista (officially Vista
SP2). But even using MSVCRT, apart from toy projects, I don't think it
is feasible to target W9X with any modern toolset unless you tweak a
fair chunk of its runtime code.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 25 Dec 2022 08:13:34 +0800
> 
> If Emacs is built with ucrt or Clang, will it still work on Windows 9X?

AFAIK, UCRT is only available for Windows XP and newer systems.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Are the sources of UCRT available somewhere (as MSVCRT sources were)?

This article seems very relevant:

https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt?view=msvc-170

At the end there is a link to a list of differences among MSVCRT and
UCRT.

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: helohe@bluewin.ch,  emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 17:14:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Please note that MinGW-w64 and MSYS2 (which includes MINGW-packages) are
> >> different projects. MSYS2 builds, packages and distributes MinGW-w64.
> >> MSYS2 decided to bump _WIN32_WINNT in our build scripts, which has
> >> implications for Emacs (see below) but that's independent of what
> >> MinGW-w64 actually, officially supports.
> >
> > So what are the details?  Which versions of Windows does MSYS2
> > support, 
> 
> Since about 1 week ago, the minimum requirement is Windows 8.1. Hardware
> requirements were also recently upgraded. A CPU from 2007 onwards should
> be fine:
> 
> https://www.msys2.org/news/#2022-10-18-new-minimum-hardware-requirements-cpus-from-20067

And the MinGW64 folks now informed me that MinGW64 switched to
Windows 10 as the default target about a year ago.  See

  https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364569522

Which in practice means building with MinGW64 on versions of
MS-Windows older than 10 is no longer safe ore recommended.

I updated the installation instructions and PROBLEMS to that effect.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > So what are the details?  Which versions of Windows does MSYS2
>> > support, 
>> 
>> Since about 1 week ago, the minimum requirement is Windows 8.1. Hardware
>> requirements were also recently upgraded. A CPU from 2007 onwards should
>> be fine:
>> 
>> https://www.msys2.org/news/#2022-10-18-new-minimum-hardware-requirements-cpus-from-20067
>
> And the MinGW64 folks now informed me that MinGW64 switched to
> Windows 10 as the default target about a year ago.  See
>
>   https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364569522
>
> Which in practice means building with MinGW64 on versions of
> MS-Windows older than 10 is no longer safe ore recommended.
>
> I updated the installation instructions and PROBLEMS to that effect.

As I just commented on the Github discussion, MinGW-w64 just set the
configure-time default for the target OS version. It still supports
previous versions. Also, MinGW-w64 distributes source, while MSYS2
distributes binaries. And the MinGW-w64 binaries distributed by MSYS2
sets the target OS version to 8.1

Re: MinGW build on master fails with Error 127

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 24 Dec 2022 20:23:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And the MinGW64 folks now informed me that MinGW64 switched to
> > Windows 10 as the default target about a year ago.  See
> >
> >   https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364569522
> >
> > Which in practice means building with MinGW64 on versions of
> > MS-Windows older than 10 is no longer safe ore recommended.
> >
> > I updated the installation instructions and PROBLEMS to that effect.
> 
> As I just commented on the Github discussion, MinGW-w64 just set the
> configure-time default for the target OS version. It still supports
> previous versions. Also, MinGW-w64 distributes source, while MSYS2
> distributes binaries. And the MinGW-w64 binaries distributed by MSYS2
> sets the target OS version to 8.1

And as I just replied there, in this case the default targets very
soon becomes the de-facto minimum supported target.  And since that
change in MinGW64 was done almost a year ago, it is reasonable to
assume that it propagated to all the important MinGW64 packages, and
thus to Emacs.

Re: MinGW build on master fails with Error 127

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > And the MinGW64 folks now informed me that MinGW64 switched to
>> > Windows 10 as the default target about a year ago.  See
>> >
>> >   https://github.com/msys2/MINGW-packages/issues/14573#issuecomment-1364569522
>> >
>> > Which in practice means building with MinGW64 on versions of
>> > MS-Windows older than 10 is no longer safe ore recommended.
>> >
>> > I updated the installation instructions and PROBLEMS to that effect.
>> 
>> As I just commented on the Github discussion, MinGW-w64 just set the
>> configure-time default for the target OS version. It still supports
>> previous versions. Also, MinGW-w64 distributes source, while MSYS2
>> distributes binaries. And the MinGW-w64 binaries distributed by MSYS2
>> sets the target OS version to 8.1
>
> And as I just replied there, in this case the default targets very
> soon becomes the de-facto minimum supported target.  And since that
> change in MinGW64 was done almost a year ago, it is reasonable to
> assume that it propagated to all the important MinGW64 packages, and
> thus to Emacs.

That's not how it works. When the MinGW-w64 "binary" (*) package is
built, MSYS2 sets the target (8.1 at the time of writing.) This setting
is frozen on the build products. This means that the MinGW-w64 package
distributed by MSYS2 will require 8.1 and will impose that requirement
on packages that link to it and, probably, also on packages that were
built with it (because of inlines or macros.)

* The package actually contains dlls, import libraries and header files,
  so it is both a bin and a dev package in Debian's pseudo-parlance.