Feature: Build riscv64 wheel

[ffgan]

Hi there.

As mentioned previously, cibuildwheel provides excellent support for different platforms. Although the cibuildwheel refactoring for other platforms is not yet complete, the Linux platform is basically usable now.

Therefore, we can discuss the issue of openblas-libs supporting riscv64 (rv64). Currently, PyPI already supports hosting rv64 wheels, and cibuildwheel also supports rv64. Many projects have already supported building rv64 wheels, such as lxml, ruff, uv, etc. They all have wheels that can be directly pip install. Regarding this, I hope openblas-libs can support rv64 wheels as soon as possible. If there's anything I need to assist with, feel free to @ me anytime. Once openblas-libs supports rv64 wheels, numpy and scipy will soon be able to gain rv64 support as well.

The upstream OpenBLAS has already added support for rv64, so we don't need to make too many changes. I attempted building for rv64 in my own fork, and the CI results show everything went smoothly. However, there are two points that need special attention:

1. The build was completed using docker+qemu, not a native build
2. The build time is quite long

For the first point, you can check my commit content for details - the modifications are very minimal.

For the second point, it's actually due to performance issues caused by virtualization, so the time required is much longer compared to native builds on other architectures.

My main question is: will openblas-libs accept wheels built using the docker+qemu approach? If acceptable, I can raise a PR very soon and ensure CI passes. If native builds are deemed necessary, we can take our time to discuss this. If there's any new relevant information, I will update this issue promptly.

---

Other Info
Co-authored by: nijincheng@iscas.ac.cn;

[mattip]

Wow, close to 3 hours for the build. From looking at the build log timestamps (compare the timestamp of the line with make -s -C test all to the beginning), it seems the vast majority of the time is in compilation. Would it be faster to cross-compile? There are some hints in the OpenBLAS documentation

[mattip]

This would mean separating the build into stages:

• make the libscipy_openblas library with a cross compiler in the manylinux docker.
• make test in a qemu docker image
• make install as we already do, this can be done in the regular manylinux docker.

[ffgan]

Wow, close to 3 hours for the build. From looking at the build log timestamps (compare the timestamp of the line with make -s -C test all to the beginning), it seems the vast majority of the time is in compilation. Would it be faster to cross-compile? There are some hints in the OpenBLAS documentation

I think it's feasible and should save quite a bit of time. I plan to try it out in a couple of days, but I'm not sure whether using cross-compilation solely for rv64 here will complicate the current repository. If possible, can this operation be used together with CMake?

[mattip]

Whatever is easiest for you. I would suggest doing the transition to CMake on linux only as a first stage, since the macOS and windows builds are very fragile.

[rgommers]

I think the common practice of this repo of supplying scipy-openblas32|64 for all platforms that PyPI supports fits well with riscv64 support.

As a heads up: for numpy/scipy this is going to be a tougher decision. We have too many such requests, and it's not feasible to support all niche (whether upcoming, legacy or just niche) platforms. We're going to have to have some policy on that; please don't expect that discussion to move very quickly.

[markdryan]

I think it's feasible and should save quite a bit of time. I plan to try it out in a couple of days, but I'm not sure whether using cross-compilation solely for rv64 here will complicate the current repository. If possible, can this operation be used together with CMake?

A simpler alternative to cross compilation would be to use native RISC-V builders to speed up the build times. These aren't available normally via github actions but RISE has just launched a new program to provide RISC-V runners to open source projects. I tried the building openblas-libs on a Scaleway EM-RV1 with 4 cores (one of the machines available via the RISE program) earlier today and it took 59 minutes. There are larger builders available (Milk-V Pioneer) we could try if this is still too slow.

You can find information about how to register a builder here. Note it says that the builders will expire after 90 days, but that default can be overridden by RISE and the builder can be made permanent. I'm not sure anyone has actually tried these builders with cibuildwheel yet, so if we want to go down this route, I suggest that either I or @ffgan try to get a fork of openblas-libs to work with one of these builders and then report back here.

As a heads up: for numpy/scipy this is going to be a tougher decision. We have too many such requests, and it's not feasible to support all niche (whether upcoming, legacy or just niche) platforms.

I was planning to enter a bug on numpy to track all the work that needs to be done before riscv64 numpy wheels can be built by the numpy project. Is it still worth doing this or would it be better to wait for the policy to be published?

Note that until a few months ago, it wasn't really possible for the numpy project to build riscv64 wheels as critical projects like cibuildwheel, manylinux and warehouse were missing riscv64 support. All three projects now support riscv64. Furthermore, numpy is known to work on riscv64 (RISE have pre-built tested wheels available here) and RISE would be able to offer native builders to improve build times, if required.

[rgommers]

I was planning to enter a bug on numpy to track all the work that needs to be done before riscv64 numpy wheels can be built by the numpy project. Is it still worth doing this or would it be better to wait for the policy to be published?

It's fine to open an issue on the NumPy issue tracker I'd say, so we have a canonical location there to add RISC-V wheels info to. Just don't expect a quick yes:)

For reference, here is a current overview of the discussion: scientific-python/summit-2025-nov#4. There's an in-person meeting over the next couple of days where I expect that topic to be discussed so more people will weigh in. Following along there may be informative.

Also, re native builders: that's potentially useful. For ppc64le we do have a native builder in the NumPy CI, so I think we'd be open to adding a native RISC-V builder as well if the runtime is fast enough. Proably needs the larger builder, 59 minutes for OpenBLAS sounds very slow (on the order of 10 min. like for Linux would be much better).

[markdryan]

Two quick updates:

• I've opened up the numpy for riscv64 issue.
• I've been trying to get the RISE RISC-V native runners to build a fork of openblas-libs with @ffgan patches applied. It's not quite working yet (we're missing nested container support), but hopefully will be soon. I'll report back here with some numbers when I get it to work.