Build Python3 for Windows 10 on ARM with Visual Studio 2019 (x86) on Windows 10 on ARM

Introduction

In the previous post, "Build 7-zip (19.00) for Windows 10 on ARM with Visual Studio 2019 (x86) on Windows 10 on ARM This time, I tried to build Python3.

I don't have much experience with Python myself, but I've seen it used occasionally as an OSS build aid script, so I thought it would be useful to make it native [here]. ](Https://bugs.python.org/issue33125) I saw an exchange that seemed to be something I could do, so I decided to take on the challenge.

Build Python3

For the time being, this time we will use the 3.8 series, which is the current Stable. Although there are some ridiculous restrictions (described later), I was able to build quickly with the following command group.

git clone https://github.com/python/cpython -b 3.8
cd .\cpython\PCbuild
build.bat -p ARM64 -c Release

Constraint

It seems that NuGet installs various external modules under . \ Cpython \ externals when building Python, but some external modules are not included for ARM64 and the build is skipped.

Among them, I thought it would be a little lonely that tkinter (TclTk), which is a standard Python GUI module, could not be used, so I tried to build TclTk.

Build tkinter (TclTk)

TclTk installed by NuGet at the time of this Python build was version 8.6.9, but I believe that the build is a little easier to pass [here](https://www.tcl.tk/software/tcltk/ Download tcl8610-src.zip and tk8610-src.zip from the download.html) site and extract them to your work location.

File content modification

1. It seems that the script does not support it, so I forcibly specified ARM64 this time. Rules.vc in. \ Tcl8.6.10 \ win Set ARM64 to MACHINE parameter on line 473 MACHINE=$(ARCH) → MACHINE=ARM64

2. Also, the cpuid function looks like an assembler, so I forcibly omitted it this time. tclWin32Dll.c in. \ Tcl8.6.10 \ win Comment out line 820 __cpuid(regsPtr, index); → /*__cpuid(regsPtr, index);*/

• It seems that the above file on the Tcl side is also referenced when building Tk, and it seems that the Tk side does not need to be modified.

Build TclTk

If expanded normally, launch a command window at the folder locations . \ Tcl8.6.10 \ win and. \ Tk8.6.10 \ win, respectively.

Prepare a toolset environment for ARM64 as usual

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x86_arm64

Now, start building!

However, for some reason, when building on Windows 10 on ARM, I get angry that "TCLSH_NATIVE is not set", so for the time being, I specified the x86 version of TclTk installed by NuGet when building python. ..

nmake -f makefile.vc release OPTS=threads TCLSH_NATIVE="work\cpython\externals\tcltk-8.6.9.0\win32\bin\tclsh86t.exe"

Basically, the build passed with the above command, but when compiling the sqlite module of the Tcl side build, there was a skip due to an error related to the resource compiler as shown below.

.\tcl8.6.10\pkgs\sqlite3.30.1.2\win\Release_ARM64_VC1926\sqlite_ThreadedDynamic\sqlite.rc(4) : error RC2167 : unrecognized VERSIONINFO field;  BEGIN or comma expected
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\rc.EXE"' :Return code'0x2'
Stop.

I thought it wouldn't affect tkinter, so I went through this time. ^^; In the future, even when I feel like it, I will investigate the handling of the resource compiler when building for ARM64.

Install TclTk

For the time being, I don't care about the difference in version numbers, and I'm stuck in the arm64 folder at TclTk, which was installed with NuGet when building Python.

nmake -f makefile.vc install INSTALLDIR="work\cpython\externals\tcltk-8.6.9.0\arm64" TCLSH_NATIVE="work\cpython\externals\tcltk-8.6.9.0\win32\bin\tclsh86t.exe"

Build tkinter (Rebuild Python)

Now that TclTk is ready, I will build tkinter (rebuild Python), but I wasn't sure if it would reconfigure well, so this time it's in . \ Cpython \ PCbuild. I launched the Visual Studio IDE from pcbuild.sln`, added tkinter in "Build Configuration" here, and rebuilt it.

I haven't verified the operation in detail, but for the time being, I managed to get to the point where the GUI window by tkinter was launched.

in conclusion

Isn't this the unique taste of a minor machine that the environment is gradually enriched while struggling? However, I hope that the official ARM64 version will be distributed as soon as possible in order to gain momentum for its widespread use.