Add riscv64 host platform support

[gounthar]

Summary

WASI SDK currently ships pre-built binaries for six host platforms (x86_64 and arm64 on Linux, macOS, Windows). I'd like to request adding riscv64-linux as a supported host platform.

Context

I successfully built WASI SDK v30 from source on native RISC-V hardware (Banana Pi F3, SpacemiT K1, rv64gc, 16 GB RAM, Debian Trixie). The build completes with zero source code patches ; only cmake flags and one post-install symlink are needed.

The full process is documented in a blog post: Building WASI SDK on RISC-V

Four workarounds required

All are cmake flags or symlinks, no source modifications:

1. Stage 2 needs Stage 1 Clang (not system GCC):
   -DCMAKE_C_COMPILER="$INSTALL_DIR/bin/clang" / -DCMAKE_CXX_COMPILER="$INSTALL_DIR/bin/clang++"

2. Skip native compiler test (Stage 1 Clang only targets wasm32):
   -DCMAKE_C_COMPILER_WORKS=ON / -DCMAKE_CXX_COMPILER_WORKS=ON

3. Skip WASIP2 targets (wit-bindgen/wasm-tools/wkg don't ship riscv64 binaries):
   -DWASI_SDK_TARGETS="wasm32-wasi;wasm32-wasip1"

4. Fix resource dir path: symlink clang-resource-dir/lib → lib/clang/21/lib

Build stats

Metric	Value
Stage 1 (LLVM+Clang+LLD)	~8-10 hours
Stage 2 (wasi-libc sysroot)	~15-20 minutes
Installed SDK size	244 MB
hello-world.wasm output	105 KB
Source patches needed	0
WASI SDK version built	30.2g1033443e5c36
Clang version	21.1.4-wasi-sdk

What this enables

With WASI SDK on riscv64, developers can do fully self-hosted WebAssembly development on RISC-V: C/C++ source → Clang (native rv64) → .wasm → iwasm (native rv64), with no x86 or ARM host needed.

This is part of a broader effort proving the full WebAssembly stack works on RISC-V, including WAMR and the Ocre runtime.

Proposal

I'd be happy to contribute:

• A CI workflow (or additions to existing CI) for riscv64 builds (likely QEMU-based initially)
• Build documentation for native riscv64 compilation
• Testing on real RISC-V hardware

The main blocker for full WASIP2 support is the lack of riscv64 binaries for wit-bindgen, wasm-tools, and wkg (Rust tools from bytecodealliance). WASIP1 works fully.

[gounthar]

For CI integration, it's worth noting that 10xEngineers' Cloud-V platform provides free RISC-V compute resources and GitHub Actions runners to open-source projects. Cloud-V is the first official RISC-V Lab Partner designated by RISC-V International.

Their hardware pool includes boards with RVV 1.0 support, and they offer GitHub Actions self-hosted runner integration. This could provide a path to riscv64 CI for wasi-sdk without requiring QEMU-based builds (which would take many hours for an LLVM build).

There's also the RISC-V-Runners/github-actions-riscv project that provides a ready-made self-hosted runner setup for RISC-V hardware.

I've opened #608 with build documentation as a first step. Happy to help set up CI integration if there's interest.

[alexcrichton]

I think it would be reasonable to game out CI integration. The primary constraint is that we basically have to use github actions default runners, there's really no other option. That's not the end of the world though because there are already platforms in CI where we cross-compile LLVM to distribute it. Would you be interested in getting that setup?

The general shape of things would be that there'd be a dedicatd builder that would create a cross-compiled LLVM distribution build which would be an artifact. Later steps in the build would then attach a wasi-sysroot compiled elsewhere to that artifact to produce the final artifact. For example this is how x86_64-macos artifacts are produced -- they're cross-compiled, never executed, and packaged later.

[alexcrichton]

Also, if you're interested, adding riscv64gc versions of tools for building wasip2 should be pretty easy. Most of those repositories are already factored to "add the lines in CI config here and that's it" in theory.

[gounthar]

Update on the wasip2 tools front: all three are now merged with riscv64 support:

• wit-bindgen: PR#1568 merged, released in v0.54.0 with riscv64gc tarball
• wasm-tools: PR#2464 merged, awaiting release
• wasm-pkg-tools (wkg): PR#196 merged, awaiting release

For wasi-sdk itself, I closed the docs PR (#608) since as you noted the real value is CI integration. I am interested in setting up the cross-compiled LLVM distribution build for riscv64. Could you point me to the existing cross-compile setup (the one used for other non-default architectures) so I can model the riscv64 config after it?

[alexcrichton]

x86_64-apple-darwin's build is cross-compiled, and the setup would probably look like arm64-linux. Linux builds are based on this container which may not build for riscv64. The goal of that container is to build the toolchain in something with an old libc to have maximal binary glibc compat. You'd likely need to set up target-specific Dockerfiles to have a custom one for riscv64. When building riscv64 you'd mirror x86_64-apple-darwin by setting WASI_SDK_CI_SKIP_SYSROOT=1

[gounthar]

Thanks for the pointers. I had a look at the x86_64-macos pattern and the CI Dockerfile.

The approach seems clear: add a riscv64-linux matrix entry cross-compiled on ubuntu-24.04, mirroring x86_64-macos with WASI_SDK_CI_SKIP_SYSROOT=1, and a target-specific Dockerfile.

One thing I checked: AlmaLinux 8 does not appear to have riscv64 cross-compilation packages in its repos. Ubuntu 24.04 does (crossbuild-essential-riscv64, gcc-riscv64-linux-gnu, etc.), so the riscv64 Dockerfile would probably need to be Ubuntu 24.04-based. The trade-off is a glibc 2.39 minimum for the resulting binary, but that should be acceptable since riscv64 only appears in relatively recent distros anyway.

Happy to be corrected if I am missing something. Before starting on a PR: what target triple should I use? I am assuming riscv64-linux-gnu for the cross-compiler and riscv64gc-unknown-wasi for the WASI target, but I want to confirm before wiring up the CMake args.

[alexcrichton]

Yeah using ubuntu-24.04 I think is fine. You might be able to go back a bit but that's fine to happen in a follow-up too. I'd recommend calling the final artifact riscv64-linux, and there's no WASI target to name so no need to worry about that.