A point-in-time build of grpcio==1.80.0 targeting win_arm64 for Python 3.12.
This repository exists because PyPI does not currently publish a win_arm64 wheel for grpcio, and building from source requires a specific configuration that is not obvious from the error messages. The wheel here was built on Windows 11 24H2 ARM64 and is provided so that the next developer who needs to install ChromaDB, opentelemetry-exporter-otlp-proto-grpc, bumble, or any other package that depends on grpcio does not have to repeat the investigation.
This repository is not maintained. It is a one-time artifact, submitted to grpc/grpc#39362 for upstream adoption. When grpc adds
windows-11-armto their wheel-build CI matrix, PyPI will publish official wheels and this repo should be considered obsolete. Until then, use what is here at your own risk.
pip install grpcio fails on Windows ARM64 because PyPI has no win_arm64 wheel and a source build trips over two non-obvious problems:
- Pip's build isolation tries to build Cython from source, which fails on Windows ARM64.
- grpcio's source paths are deep enough that pip's default temporary build directory pushes them past Windows's 260-character path limit.
The fix is to install Cython explicitly into your venv, disable build isolation, and extract the grpcio source to a short path such as C:\g\grpcio before building. This repository documents that process and provides a PowerShell script that runs it end to end.
Most users only need the wheel from the latest release.
Reference build used to produce the wheel in this repository:
| Item | Value |
|---|---|
| CPU | ARM64 (Snapdragon X Elite) |
| OS | Windows 11 24H2 ARM64 |
| Python | 3.12 ARM64 (from python.org) |
| Toolchain | Visual Studio Build Tools 2022, MSVC 14.44.35207 |
| Windows SDK | 10.0.26100.0 |
| grpcio version | 1.80.0 |
| Target | win_arm64 |
| Wheel filename | grpcio-1.80.0-cp312-cp312-win_arm64.whl |
| SHA-256 | 1bd2fe31fae074ef469789e0a74226f4a360512de64aa2a7cf7000c363f597c8 |
| Wheel size | 4,489,895 bytes |
| Build duration | 30–90 minutes depending on hardware |
Your environment does not need to match every patch version, but it must be an ARM64 Python interpreter and must include the ARM64 MSVC build-tools component.
Download the wheel from the latest release, then run:
pip install grpcio-1.80.0-cp312-cp312-win_arm64.whlVerify the wheel before installing:
Get-FileHash grpcio-1.80.0-cp312-cp312-win_arm64.whl -Algorithm SHA256
# Expected: 1BD2FE31FAE074EF469789E0A74226F4A360512DE64AA2A7CF7000C363F597C8That is the only command most people need. The rest of this document is for anyone who wants to build their own wheel, understand why the stock build fails, or adapt this process for a different grpcio version or Python version.
If you want to reproduce the wheel rather than trust this repository's artifact, the process takes 30 to 90 minutes depending on hardware. The included build-grpcio-win-arm64.ps1 script encodes all of this and runs it end-to-end with preflight checks.
Install the following before starting. Skip items you already have.
- Python 3.12 ARM64 from python.org. Must be the ARM64 installer, not the AMD64/Intel installer running under emulation. Verify with
python -c "import platform; print(platform.machine())"— expected output isARM64. - Visual Studio Build Tools 2022 with the "Desktop development with C++" workload and the ARM64 build tools component. The default install does not include ARM64; you must explicitly check it.
- A Python virtual environment to build into. The wheel embeds the Python version it was built for, but not the specific venv path.
.\build-grpcio-win-arm64.ps1 -VenvPath C:\path\to\your\.venvThe script performs preflight checks (ARM64 Python, Visual Studio ARM64 tools, LongPathsEnabled, PyPI reachability), installs the build prerequisites into your venv, extracts the source to a short path, runs the build, verifies the wheel, and runs a smoke test. If anything is missing or misconfigured, it reports exactly what to fix.
All paths are configurable. For example, to build into a custom short directory:
.\build-grpcio-win-arm64.ps1 -VenvPath C:\path\to\your\.venv -WorkRoot C:\x -TempRoot C:\tmpIf you prefer to run the steps manually rather than trust the script, they are:
Run this in an elevated PowerShell (right-click PowerShell, "Run as Administrator"):
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" `
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -ForceVerify it stuck:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled
# Expected: LongPathsEnabled REG_DWORD 0x1Restart your shell (and ideally your machine) after setting this. Some services cache the flag.
In a normal (non-elevated) PowerShell where you will run the build:
$env:TMP = "C:\t"
$env:TEMP = "C:\t"
New-Item -ItemType Directory -Force -Path C:\t | Out-NullThis is per-session. If you open a new terminal, set it again.
& "C:\path\to\your\.venv\Scripts\pip.exe" install cython setuptools wheelThe cython step installs a pre-built cp39-abi3-win_arm64 wheel from PyPI. This is the single most important non-obvious prerequisite. Without it, pip's build isolation will try (and fail) to build Cython from source during grpcio's build. Installing it explicitly into the venv, combined with --no-build-isolation in step 5, bypasses that trap.
Remove-Item -Recurse -Force C:\g -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path C:\g | Out-Null
Set-Location C:\g
& "C:\path\to\your\.venv\Scripts\pip.exe" download grpcio==1.80.0 `
--no-binary :all: --no-deps -d C:\g
tar -xzf C:\g\grpcio-1.80.0.tar.gz -C C:\g
Rename-Item C:\g\grpcio-1.80.0 C:\g\grpcioThe extraction to C:\g\grpcio (12 characters) instead of pip's default temporary directory is what keeps the deepest source paths under 260 characters. This matters.
Set-Location C:\g\grpcio
& "C:\path\to\your\.venv\Scripts\python.exe" -m pip wheel . `
--no-build-isolation --no-deps -w C:\g\wheels -v 2>&1 | `
Tee-Object -FilePath C:\g\build.logExpect 30 to 90 minutes depending on hardware. The build is single-threaded for most of its duration; additional cores do not significantly help.
Output: C:\g\wheels\grpcio-1.80.0-cp312-cp312-win_arm64.whl
Get-FileHash C:\g\wheels\grpcio-1.80.0-cp312-cp312-win_arm64.whl -Algorithm SHA256The hash will not match the one in this repository if you rebuild — different build timestamps and paths are embedded in the wheel metadata. This is expected and does not indicate a problem. The wheel is still functionally equivalent.
& "C:\path\to\your\.venv\Scripts\pip.exe" install C:\g\wheels\grpcio-1.80.0-cp312-cp312-win_arm64.whl
& "C:\path\to\your\.venv\Scripts\python.exe" -c @"
import grpc
print('version:', grpc.__version__)
ch = grpc.insecure_channel('localhost:50051')
print('channel created:', ch)
ch.close()
print('OK')
"@If all three lines print and the script exits cleanly, the wheel is functional.
The build script performs its own verification and smoke test automatically. When it finishes successfully it prints:
Build succeeded
and writes SHA256SUMS.txt and a copy of the build log next to the wheel.
Running pip install grpcio --no-binary :all: on Windows ARM64 produces a series of errors that look unrelated to each other but share a common root cause. The errors are not, as the community has sometimes assumed, evidence that Windows ARM64 is architecturally unsupported. They are symptoms of two specific and fixable problems:
-
Pip's default build isolation rebuilds Cython from source, even though Cython publishes a working
win_arm64wheel on PyPI. When pip creates an isolated build environment for grpcio, it installs Cython into that environment via a pip resolver that does not find the wheel, and attempts to build Cython from source. This build fails at the link stage withLNK1104: cannot open file, referring to a linker output file whose path has been truncated. -
Grpcio's source tree contains paths deep enough to exceed Windows's legacy 260-character path limit when combined with pip's default temporary build directory. The deepest affected paths are in
src/core/ext/upb-gen/envoy/extensions/..., which regularly produce source filenames around 180 characters on their own. When pip nests this tree insideC:\Users\<user>\AppData\Local\Temp\pip-install-xxxxxxxx\grpcio_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\, the total exceeds the limit. This manifests asC1083: Cannot open compiler generated file: ''during compile, orLNK1181: cannot open input fileduring link, depending on which tool is first to trip over the truncation.
Enabling Windows long-path support helps but does not fully resolve the issue, because not every tool in the MSVC chain uses long-path-aware APIs consistently. The reliable fix is to extract the source to a short path and build from there.
Before describing the fix, it is worth being explicit about what does not need fixing.
Grpcio's setup.py already recognizes win-arm64 as a build target. It emits the following messages during configure:
Found cython-generated files...
SSE2 not enabled on win-arm64 platform
ASM Builds for BoringSSL currently not supported on: win-arm64
These are correct behaviors. The first confirms Cython-generated C sources are in the tree and do not need regeneration. The second disables x86 SIMD intrinsics. The third skips BoringSSL's hand-tuned assembly files (which have no ARM64 Windows variant) and falls back to the portable C crypto implementation.
No C or C++ changes are required for grpcio to compile on Windows ARM64. The ARM64 MSVC toolchain compiles every source file in the grpcio tree — BoringSSL (pure C path), abseil, re2, c-ares, protobuf, upb, and grpc core C++ — producing only benign size_t / int-width conversion warnings identical to the ones the x64 build emits. The architectural work is already done; what is missing is the CI infrastructure to build it regularly, and a build configuration that avoids the path-length cliff.
The source path is too long. Confirm that you extracted to C:\g\grpcio and not somewhere deeper. Confirm $env:TMP is set to C:\t in the shell where you are running the build, not just the one where you set it. Confirm LongPathsEnabled is 0x1 in the registry.
Same root cause as the above, at a later stage. Same fixes apply. If you are certain your paths are short, confirm you are not running in a terminal with a stale environment from before the registry change; close and reopen PowerShell entirely.
You ran --no-build-isolation without installing setuptools into your venv. Run pip install setuptools wheel in the venv first.
You ran the build without first installing Cython into the venv, so pip's build isolation is trying to build Cython from source. Run pip install cython in the venv and retry with --no-build-isolation.
The build process should work. The wheel filename will change to reflect the new Python version (cp311 or cp313). The SHA-256 in this repository only applies to the Python 3.12 build. Do not mix wheels across Python versions.
Probably. The fundamental issues — path length and build isolation — are not version-specific. Change grpcio==1.80.0 in step 4 to your desired version. If the build fails, check whether grpcio has changed its build system in a way that invalidates these instructions.
This is a standard grpcio wheel. It includes the compiled grpc._cython.cygrpc Python extension and all supporting Python modules. It does not include grpcio-tools, grpcio-reflection, or any other grpc ecosystem package; those are separate wheels that must be installed separately. At the time of this writing, grpcio-tools and friends have the same Windows ARM64 gap as grpcio itself and would need a similar build process to produce.
This work exists because of grpc/grpc#39362. The maintainers have acknowledged the request and assigned engineers, but at the time of this writing no PR has been opened and no work has been started.
The scope of what upstream needs to do, based on this investigation, is narrower than the issue thread suggests. The architectural support in setup.py already handles Windows ARM64 correctly. What remains is:
- Add
windows-11-armto the wheel-build matrix in.github/workflows/. - Configure the runner to have
LongPathsEnabled=1and a shortTMPDIR. - Optionally, teach the build system to emit
\\?\-prefixed paths when invoking MSVC tools, which would remove the TMPDIR requirement. - Document the Windows ARM64 build requirements in the project README.
This is a CI configuration change plus a documentation supplement. No C++ changes. No platform-specific code paths.
- One Python version validated. The reference wheel is for Python 3.12. The build script supports other versions, but they are not validated by this repository.
- One grpcio version validated. The reference build is
grpcio==1.80.0. Newer versions probably work, but the wheel filename, SHA-256, and possibly the build prerequisites may differ. - Build is slow and mostly single-threaded. Expect 30–90 minutes even on fast hardware. Additional cores do not significantly reduce wall-clock time.
- Windows long-path support is necessary but not sufficient. You must still extract the source to a short path such as
C:\g\grpcio. - Only the core grpcio wheel is built. grpcio-tools, grpcio-reflection, and related packages are out of scope.
- Not an official grpcio distribution. This is a community build. Upstream adoption is tracked at grpc/grpc#39362.
- Not maintained. See NOT-MAINTAINED.md for exactly what that means.
To reproduce the reference wheel:
- Install Python 3.12 ARM64 and Visual Studio Build Tools 2022 with the ARM64 component.
- Create a venv:
python -m venv C:\path\to\your\.venv. - Run the build script:
.\build-grpcio-win-arm64.ps1 -VenvPath C:\path\to\your\.venv. - Inspect the output in
C:\g\wheels\and compare the smoke-test output to the verification section above.
If you rebuild, your wheel's SHA-256 will differ from the published one because wheel metadata embeds timestamps and paths. Functional equivalence is confirmed by the smoke test, not by hash equality.
The build wrapper script, documentation, and this README are released under the PolyForm Noncommercial License 1.0.0.
The wheel artifact is a binary build of grpcio, which is itself Apache 2.0 licensed by the grpc authors. This repository claims no copyright over the wheel contents; it is redistributed under grpc's original license.
Author: Dr. Lucas Root, Ph.D. — info@lucasroot.com