I can reproduce and build the Windows ARM64 version successfully, and the resulting executable behaves correctly in my functional testing. I haven't run the upstream test suite on Windows because its run_make_tests.bat harness requires Perl, which I don't have installed in my Windows environment.
> On 23 Aug 2026, at 06:24, Eli Zaretskii <[email protected]> wrote: > >> From: Paul Smith <[email protected]> >> Cc: Eli Zaretskii <[email protected]> >> Date: Sat, 22 Aug 2026 15:55:28 -0400 >> >> On Tue, 2026-08-18 at 13:42 +0200, iain wrote: >>> The Windows build script does not currently provide an ARM64 option, >>> but adding: >> >> Thank you I can add a change like this. >> >>> The resulting build then fails in arscan.c with: >>> stdint.h(45): error C2632: '__int64' followed by 'long' is illegal >>> stdint.h(46): error C2632: '__int64' followed by 'long' is illegal >>> The cause appears to be in src/config.h.W32. The definitions >>> of HAVE_INTTYPES_H and HAVE_STDINT_H are currently guarded >>> by __MINGW32__: >>> >>> When compiling with MSVC, __MINGW32__ is not defined, even though >>> MSVC supplies both headers. >> >> I think the reason for this is that older versions of MSVC prior to >> MSVC 2010, do not provide these headers. Eli, do you know if there was >> another reason? > > ARM64 support on Windows in general and in MSVC in particular is > relatively new. I think in the long run we will need someone who can > build and test Make on such a system, to be able to support that > platform adequately. In particular, it is not clear whether the OP > ran the test suite after building Make, and if so, what were the > results. > >> If that was the only issue we could replace the check with something >> like: >> >> #if __MINGW32__ || (defined(_MSC_VER) && (_MSC_VER >= 1600)) > > Sure, if someone verifies that MSVC versions 16 and higher have > stdint.h, regardless of the underlying platform. I don't have MSVC > and cannot verify that myself.
