CPython now officially supports 64-bit RISC-V Linux, marking a formal change in the interpreter’s platform-support policy. The target is listed as riscv64-unknown-linux-gnu and is classified as a Tier 3 platform under PEP 11.
For developers and platform teams, this means RISC-V is no longer only an architecture being tested informally or by individual projects. It has a defined CPython support status, real-hardware buildbot coverage, and named maintainers. However, Tier 3 has important limits: failures do not block CPython releases, and the platform does not have a response-time service-level agreement.
What changed
The change formalizes support for 64-bit RISC-V Linux rather than announcing a new CPython release or a universal set of RISC-V binaries. The supplied announcement does not identify a specific CPython release, commit, or distribution package as the point where support was added.
Under PEP 11, Tier 3 support requires both a reliable buildbot and at least one core developer signed up to support the platform. The RISC-V entry names Stan Ulbrych and Emma Smith as contacts. The support effort included testing on real hardware, architecture-specific fixes, build-support improvements, bug reports, and patch reviews.
The Python announcement also credits the RISE Project with providing RISC-V machines for CPython buildbots and architecture-specific debugging. That infrastructure gives the project a practical way to exercise CPython on the target architecture instead of relying solely on cross-compilation or emulation.
What Tier 3 means in practice
Tier 3 is formal support, but it is not equivalent to the strongest support level in CPython’s platform policy. A failure on a Tier 3 platform does not block a CPython release, and PEP 11 provides no response-time SLA for resolving such failures.
That distinction matters when teams evaluate RISC-V for production systems or release pipelines. A project can reasonably treat riscv64-unknown-linux-gnu as an officially supported CPython target, while still planning for slower issue response and less release-gating coverage than on higher-tier platforms.
The announcement identifies promotion to Tier 2 and architecture-specific performance optimizations as longer-term goals. Those goals should not be read as completed changes. No authoritative performance benchmark was supplied, so current CPython performance on RISC-V should be measured for each workload rather than assumed from the support designation.
Build and test considerations
CPython’s official build documentation provides general source-build guidance. It states that a build requires a C11 compiler, thread support, and IEEE 754 floating-point support. Optional standard-library modules can require additional development libraries, and the configuration documentation describes the available configure options.
That documentation is not a RISC-V-specific installation guide. It does not provide a dedicated RISC-V command sequence, compiler mapping, hardware requirement, or exact toolchain and libc matrix for the PEP 11 entry. Teams should therefore use the general CPython build instructions while validating their own compiler, operating system, libraries, and target hardware.
Testing on actual RISC-V hardware is especially relevant for platform maintainers. The RISE RISC-V Runners project documents GitHub Actions jobs running on dedicated real RISC-V hardware. Its documented setup includes an ubuntu-24.04-riscv workflow label and linux/riscv64 runner images.
That service provides a potential path for architecture-aware testing, but the available evidence does not establish that CPython’s main CI has completed integration with it. The existence of the RISE runner service should not be described as proof that every CPython change is already tested in the project’s primary CI system.
Package distribution is improving, but remains uneven
RISC-V support in CPython does not automatically make the broader Python package ecosystem compatible. Individual packages may still need architecture-specific fixes, native dependencies, or publishing work.
There is, however, documented infrastructure for building some RISC-V Linux wheels. The PyPA manylinux project documents riscv64 images for manylinux_2_39 and musllinux_1_2. The documented RISC-V manylinux_2_39 image uses GCC 14, targets distributions with glibc 2.39 or later, and is marked alpha. PyPA also documents a RISC-V musllinux_1_2 image.
These images establish that package-building infrastructure exists; they do not establish universal wheel availability or compatibility for a particular package. They also do not imply support for every RISC-V distribution, libc implementation, or operating-system configuration.
What you should do
- Identify the exact target. Confirm that your deployment matches the documented CPython target,
riscv64-unknown-linux-gnu, rather than assuming that all RISC-V operating systems are covered. - Build from the official documentation. Review CPython’s general configure and build prerequisites, including the C11 compiler, threading support, IEEE 754 floating-point support, and optional-library requirements.
- Test on representative hardware. Run your application and test suite on the RISC-V machines or environments used for deployment. Do not infer performance or package compatibility from the Tier 3 designation.
- Plan CI coverage deliberately. Investigate RISC-V hardware runners such as the documented RISE infrastructure, while confirming how they fit into your own GitHub Actions or other CI workflows. Do not assume CPython’s main CI already provides this coverage.
- Audit native dependencies and wheels. Check each important package separately. For teams producing wheels, evaluate the documented PyPA RISC-V images and account for the alpha status of the
manylinux_2_39image. - Set appropriate support expectations. Tier 3 failures do not block CPython releases and have no response-time SLA, so release and incident plans should include local testing and fallback options where the platform is business-critical.
Availability and remaining limits
The verified change is platform-policy support for 64-bit RISC-V Linux. It is not evidence of general-purpose prebuilt CPython installers, broad distribution-package adoption, or completed support across all Python packages, compilers, tooling, and infrastructure.
The announcement describes broader ecosystem support, direct CI integration, performance work, and possible Tier 2 promotion as ongoing or future work. For now, the practical interpretation is narrower and useful: CPython has a recognized RISC-V Linux target with formal Tier 3 requirements, real-hardware support infrastructure, and emerging package-build coverage, but teams still need to validate their own software stack.
