python-build-standalone
python-build-standalone copied to clipboard
indygreg
Add ARM64 builds for Windows
We're failing missing applink.c:
cpython> 38>ClCompile:
cpython> C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.41.34120\bin\HostX64\arm64\CL.exe /c /I"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\openssl\arm64\include" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\Include" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\Include\internal" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\Include\internal\mimalloc" /I"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\PCbuild\obj\\313arm64_PGInstrument\pythoncore\\" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\PC" /Zi /nologo /W3 /WX- /diagnostics:column /MP /O2 /Oi /Oy- /GL /D _CRT_SECURE_NO_WARNINGS /GF /Gm- /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\PCbuild\obj\313arm64_PGInstrument\_ssl\\" /Fd"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\PCbuild\obj\313arm64_PGInstrument\_ssl\vc143.pdb" /external:W3 /Gd /TC /analyze- /FC /errorReport:queue /utf-8 "C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\openssl\arm64\include\openssl\applink.c"
cpython> applink.c
cpython> 38>C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\openssl\arm64\include\openssl\applink.c(1,1): error C1083: Cannot open source file: 'C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\openssl\arm64\include\openssl\applink.c': No such file or directory [C:\Users\RUNNER~1\AppData\Local\Temp\python-build-3k85bya8\Python-3.13.0\PCbuild\_ssl.vcxproj]
cpython> (compiling source file '../../../../../../../RUNNER~1/AppData/Local/Temp/python-build-3k85bya8/openssl/arm64/include/openssl/applink.c')
on amd64, you can see we copy this file
openssl> *** Installing runtime libraries
openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install'
openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64'
openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/bin'
openssl> Copying: libcrypto-1_1-x64.dll to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/bin/libcrypto-1_1-x64.dll
openssl> Copying: libssl-1_1-x64.dll to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/bin/libssl-1_1-x64.dll
openssl> Copying: libcrypto-1_1-x64.pdb to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/bin/libcrypto-1_1-x64.pdb
openssl> Copying: libssl-1_1-x64.pdb to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/bin/libssl-1_1-x64.pdb
openssl> *** Installing development files
openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/include'
openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/include/openssl'
openssl> Copying: ./ms/applink.c to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-upok1jaj/x64/install/64/include/openssl/applink.c
but we don't on arm64
2024-10-30T14:25:05.2679998Z openssl> *** Installing runtime libraries
2024-10-30T14:25:05.2957214Z openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install'
2024-10-30T14:25:05.2959360Z openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64'
2024-10-30T14:25:05.2961110Z openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/bin'
2024-10-30T14:25:05.3572257Z openssl> Copying: libcrypto-3-arm64.dll to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/bin/libcrypto-3-arm64.dll
2024-10-30T14:25:05.3574146Z openssl> Copying: libssl-3-arm64.dll to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/bin/libssl-3-arm64.dll
2024-10-30T14:25:05.4293375Z openssl> Copying: libcrypto-3-arm64.pdb to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/bin/libcrypto-3-arm64.pdb
2024-10-30T14:25:05.4295870Z openssl> Copying: libssl-3-arm64.pdb to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/bin/libssl-3-arm64.pdb
2024-10-30T14:25:05.4709900Z openssl> *** Installing development files
2024-10-30T14:25:05.4964299Z openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/include'
2024-10-30T14:25:05.4966851Z openssl> created directory `C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/include/openssl'
2024-10-30T14:25:05.5798950Z openssl> Copying: ./include/openssl/aes.h to C:/Users/RUNNER~1/AppData/Local/Temp/openssl-build-hynbk0h3/arm64/install/arm64/include/openssl/aes.h
Looks like -D"OPENSSL_USE_APPLINK" is set on amd64 but not arm64
By manually copying the applink.c file, we make it to
2024-10-30T17:22:46.9472354Z Traceback (most recent call last):
2024-10-30T17:22:46.9481385Z File "D:\a\python-build-standalone\python-build-standalone\cpython-windows\build.py", line 2046, in <module>
2024-10-30T17:22:46.9482543Z sys.exit(main())
2024-10-30T17:22:46.9483423Z File "D:\a\python-build-standalone\python-build-standalone\cpython-windows\build.py", line 2010, in main
2024-10-30T17:22:46.9484169Z tar_path = build_cpython(
2024-10-30T17:22:46.9485025Z File "D:\a\python-build-standalone\python-build-standalone\cpython-windows\build.py", line 1596, in build_cpython
2024-10-30T17:22:46.9486058Z tests = subprocess.run(
2024-10-30T17:22:46.9486654Z File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\subprocess.py", line 505, in run
2024-10-30T17:22:46.9488654Z with Popen(*popenargs, **kwargs) as process:
2024-10-30T17:22:46.9489422Z File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\subprocess.py", line 951, in __init__
2024-10-30T17:22:46.9491810Z self._execute_child(args, executable, preexec_fn, close_fds,
2024-10-30T17:22:46.9492618Z File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\subprocess.py", line 1420, in _execute_child
2024-10-30T17:22:46.9495394Z hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
2024-10-30T17:22:46.9496711Z OSError: [WinError 216] This version of %1 is not compatible with the version of Windows you're running. Check your computer's system information and then contact the software publisher
2024-10-30T17:22:46.9845209Z ##[error]Process completed with exit code 1.
Where we fail to run the PGO tests because, of course, we're not on an ARM runner.
https://github.com/indygreg/python-build-standalone/blob/00ea84cd2a525c8d20566482633903878bae2996/cpython-windows/build.py#L1596-L1602
I don't really know what the plan is here. There aren't public ARM Windows runners (though they might be eventually https://github.com/actions/runner-images/issues/10820 / https://github.com/github/roadmap/issues/970). We (Astral) could pay for runners, but I can't set that up in this repository.
We could skip PGO, but we're still going to fail later (we need to invoke python.exe for various things).
As a note, before releasing this we need to add proper prioritization for these builds to uv — as arm64 wheels are not prevalent we may not want to actually use these builds by default.
before releasing this we need to add proper prioritization for these builds to uv — as arm64 wheels are not prevalent we may not want to actually use these builds by default
FWIW, we still consider them experimental in upstream, and I'm regularly tracking whether to make them non-experimental. Right now, that's not going to happen anytime soon, unless I get sick of the people who are meant to be using them going "I'm not going to fix my package/tool until it's non-experimental" when it's still experimental because they haven't fixed anything (okay, clearly I'm already sick of them, but I can't shout at them all at once 😆 )
When we think it's time to unleash users on these builds by default, it'll be announced as part of an upstream beta release (or earlier, but probably not earlier - definitely no later than beta).
3.9 fails validation due to missing tkinter extension module
2025-04-15T00:31:54.0323918Z cpython> WARNING Failed to find TCL_LIBRARY
...
2025-04-15T00:32:03.7913938Z cpython> extension not present: _tkinter
3.13 fails more eagerly with the same problem
2025-04-15T00:16:13.8958569Z cpython> replacing `b'<_TclTkDLL Include="$(tcltkdir)\\bin\\$(tclZlibDllName)" />'` with `b''` in C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\_tkinter.vcxproj
....
2025-04-15T00:19:07.5442513Z cpython> ClCompile:
2025-04-15T00:19:07.5530958Z cpython> C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.43.34808\bin\HostX86\arm64\CL.exe /c /I"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\cpython-bin-deps-e3c3e9a2856124aa32b608632a52742d479eb7a9\arm64\include" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\Include" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\Include\internal" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\Include\internal\mimalloc" /I"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\obj\\313arm64_PGInstrument\pythoncore\\" /I"C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PC" /Zi /nologo /W3 /WX- /diagnostics:column /MP /O2 /Oi /Oy- /GL /D "Py_TCLTK_DIR=\"C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\python-build-ojo0tbal\\cpython-bin-deps-e3c3e9a2856124aa32b608632a52742d479eb7a9\\arm64\"" /D WITH_APPINIT /D _Py_USING_PGO=1 /D WIN32 /D "PY3_DLLNAME=L\"python3t\"" /D _WIN32 /D NDEBUG /D _ARM64_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /D _WINDLL /GF /Gm- /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\obj\313arm64_PGInstrument\_tkinter\\" /Fd"C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\obj\313arm64_PGInstrument\_tkinter\vc143.pdb" /external:W3 /Gd /TC /analyze- /FC /errorReport:queue /utf-8 ..\Modules\_tkinter.c ..\Modules\tkappinit.c
...
2025-04-15T00:19:31.0026512Z cpython> "C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\_tkinter.vcxproj" (Build target) (41) ->
2025-04-15T00:19:31.0027038Z cpython> (ClCompile target) ->
2025-04-15T00:19:31.0027984Z cpython> C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\Modules\tkappinit.c(16,10): error C1083: Cannot open include file: 'tcl.h': No such file or directory [C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\_tkinter.vcxproj]
2025-04-15T00:19:31.0029929Z cpython> C:\Users\runneradmin\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\Modules\_tkinter.c(52,12): error C1083: Cannot open include file: 'tcl.h': No such file or directory [C:\Users\RUNNER~1\AppData\Local\Temp\python-build-ojo0tbal\Python-3.13.3\PCbuild\_tkinter.vcxproj]
Looks like this is because the artifact we use for tcl/tk does not include arm64 binaries — so we'll try the newer version.
Okay now this is working on 3.11+, I don't want to get side-tracked debugging the 3.9 / 3.10 tkinter problems.
We'll also need to add these builds to the release targets.
I don't want to get side-tracked debugging the 3.9 / 3.10 tkinter problems
Neither did I, which is why we never enabled it upstream for those versions.
Honestly, I wouldn't bother with 3.11 and 3.12 either. There are potentially bugs in those that were never fixed.
There's also a known compiler bug in 14.43 (searching build output for 14.4 should find your version) that causes OpenSSL to crash. It's fixed in 14.44 (not released yet) and didn't exist in 14.40 (possibly also 14.41), so if you run into that issue also don't waste too much of your time. If you're using the same pre-built OpenSSL we use for CPython then you should be okay.
Hi @zanieb, thank you for your work on this PR! I was wondering if there are any pre-built binaries available for testing the ARM64 Windows build on devices like the Surface Pro 9. If not, would it be okay if I try compiling this branch to test it myself? Thanks in advance!
@gr3vios If you're just looking to test Python itself, then there are releases on python.org and CI-friendly packages at https://nuget.org/packages/pythonarm64 that are pre-built. All Windows builds are essentially standalone, the installers are mainly there for people who like installers (most users).
If you were planning to test uv, then I expect you'll have to wait for the build support here to be completed.
The artifacts are also available from this branch at https://github.com/astral-sh/python-build-standalone/actions/runs/14574945166?pr=387
If I understand correctly,
- uv publishes Windows arm64 binaries, and Windows users will get them if they install uv according to the website
- uv prefers arm64 Python on arm64 Windows, but because they are not available, it falls back to x64 Python
- nothing in the sync process for teaching uv about python-build-standalone releases excludes arm64
i.e., once this merges, the next time we sync python-build-standalone releases in uv, arm64 Windows users will get an arm64 Python.
If so, I think we should hold off on releasing this until we have some way to default uv users to x64 for the time being. (See https://github.com/astral-sh/uv/issues/12906#issuecomment-2836022594).
Yes, but I can't easily test an implementation of that until these are released. I think it'll be trivial to exclude them if we decide it's too much work to figure out how to adjust the preferences, so I don't really see it as a blocker — just something to be aware of when we release and sync.