RISCV64 support

[JuniorJPDJ]

Would be cool to see manylinux images for riscv64 (musllinux cannot be easily supported as alpine stable still doesn't have support for riscv). This architecture is rising fast now ;D

[mayeut]

This will depend on RHEL support for risk-v (or a derivative like AlmaLinux/RockyLinux).
Until then, nothing will happen as using ubuntu or a debian derivative as a base image is most likely a no-go here (c.f. #1012)

[JuniorJPDJ]

Ubuntu 20.04 is the first officially supporting RISC-V distro anyway and it has GCC9 which is new enough. Why not just support RISC-V on Ubuntu 20.04 starting from manylinux_2_31? Old distro releases will anyway not add new CPU architecture support, so we are covered.

[mayeut]

Even if we wanted to add a base image using ubuntu 20.04 which I'm still not sure wouldn't be seen as a regression by the community (unless adding only a RISC-V image), the question of CI would remain. qemu is a no go here as it is way to slow to build images (we were often hitting GHA time limit on ppc64le when travis-ci was broken on that architecture).

[JuniorJPDJ]

I was thinking about adding this images for only RISC-V. QEMU is a problem here then.

[lexiforest]

Given that alpine has offcially supported riscv in 3.20, is there any plan to add musllinux support for riscv?

[mayeut]

It won't be added until those wheel are accepted by PyPI which in turn might require a new PEP to be written for RISCV64 according to PEP 600 & the problem raised in https://discuss.python.org/t/packaging-support-for-riscv64/58475/7 regarding compatibiility.

[yzewei]

I was thinking about adding this images for only RISC-V. QEMU is a problem here then.

easy
use buildx...

[mayeut]

well buildx still uses qemu, that's what was used for ppc64le on GHA

[olof-nord]

I was curious on this topic, and decided to document the current OS-level risc-v support.

• Debian will add official stable support for riscv64 port to Debian 13. (Release Date TBA)
• Ubuntu already supports risc-v (its what I use on my server too).
• Fedora have started a Special Interest Group and are publishing semi-official docker images.

As for RHEL/AlmaLinux/RockyLinux there is not much to find, other than that the vendors are looking at the architecture.

Red Hat and RISC-V: To the far edge and beyond

[jonathanspw]

@eshattow we're building with P550s right now and we also of course have VF2 and similar, but the P550s are the fastest we have at the moment. Do you have access to something better?

[davidlt]

@eshattow there are strict requirements for the hardware to be installed in the datacenter where Fedora infrastructure lives. The SBCs without proper datacenter form factor, built-in BMC, commercial support, etc. are not valid options. Otherwise we are using the same boards (Unmatched, VF2s, P550-based boards, Spacemit K1/M1-based boards, etc.) as a community. Naturally the upstream support is mainly limited to Unmatched and VF2 boards. Typically upstreaming starts some months (6 - 12 months) after hardware is available on the market. I would say it takes another 12 - 24 months before there is enough stuff that it gets useful in the build farm. P550 and Spacemit K1/M1 based boards are still using vendor kernel with some modifications in some cases.

[eshattow]

U74 core (SiFive P550, StarFive JH7110) CPU boards with 1GB RAM per-core and NVMe storage are good for this work. Some especially memory intensive compiles as the Rust language or Qt infrastructure do require a swapfile (or greater than 1GB RAM per-core). Linux Kernel compiles do benefit from higher CPU core count but it is not necessary. Real hardware in this way is quite a lot more performant today than cross-platform emulation.

I have remote access to a Pioneer box (lots of cores and RAM). It's an interesting party trick to compile a Linux Kernel in the order of a few minutes on the many-core Pioneer as compared to a few hours on U74 few-core CPU board. The same quick compile time is achievable however with distcc and multiple U74 core boards. It just is not necessary, slow compile times are fast enough to keep up with build requirements as proven by Debian Project build infrastructure.

[markdryan]

Over at the wheel_builder project, we're in the process of switching the custom manylinux images we use to build riscv64 wheels from Ubuntu 22.04 to RockyLinux 10. RockyLinux announced official support for riscv64 back in May.

The patch needed to create a manylinux_2_39_riscv64 image based on RockyLinux 10 is fairly trivial, especially when compared with our previous patches for our manylinux_2_35_riscv64 images that were based on Ubuntu.

If you look at the patch you'll notice that we needed to account for some missing packages

• libdb which I think is deprecated
• EPEL which doesn't currently exist for riscv64
• gcc-toolset

The lack of gcc-toolset doesn't appear to be a blocker as RockyLinux 10 ships with gcc-14.2.1. I asked the RockyLinux 10 developers about gcc-toolset support and was told that it would be added in RockyLinux 10.1 in which gcc will be upgraded to gcc 14.3.1 and gcc-toolset-15-* will appear.

Another nice feature of RockyLinux 10, from the point of view of building Python packages, is that it is compiled with rv64gc (a set of extensions that all riscv64 application processors support). This means that wheels built on RockyLinux 10 won't be susceptible to issues such as manylinux_2_34 x86-64 builds produce binaries that are not compatible with all x86-64 CPUs as any distro supplied libraries that get vendored inside wheels will be guaranteed to work on all present and future riscv64 hardware.

So far we've successfully built numpy==2.3.1, scipyopenblas[32|64]==v0.3.29.0.0 and pandas==2.3.1 with our new RockyLinux 10 based manylinux_2_39_riscv64 image.

The one issue we did run into is that there is a problem with the current rockylinux/rockylinux:10 docker images that can cause dnf to fail. This is due to a bug in zlib-ng. Updating zlib-ng fixes the problem, but that's a little difficult to do without a working dnf. So a manual upgrade of zlib-ng is required before running dnf upgrade. As the crash is intermittent, you can just run dnf upgrade until it passes or create the image on a machine that does not support RVV 1.0 to avoid the crash.

Might RockyLinux 10 be considered as a suitable base for an official manylinux_2_39_riscv64 image?

[mayeut]

If you look at the patch you'll notice that we needed to account for some missing packages

I stumbled upon the same things in #1743
libdb has already been removed in #1806

Might RockyLinux 10 be considered as a suitable base for an official manylinux_2_39_riscv64 image?

yes, I think one thing remaining before doing so is getting PyPI to accept downloads (c.f. pypi/warehouse#18243).
@markdryan, given what you're saying about the "ABI" of rockylinux/rockylinux:10 (still using rv64gc/rva20u64), I guess the point could be made over there that a PEP is not required & that rva22u64 or later might/should be handled by https://wheelnext.dev/proposals/pepxxx_wheel_variant_support/ ?