RISC-V compilation?

[puma314]

I saw recently there were updates to the rust/build.rs for the Rust bindings to get this library to compile in an sgx target. It would be really useful to have this library compile to theriscv32 target, which would be really useful within the context of zkVMs. Is it possible to add logic in the build.rs to allow this library to compile to the riscv32 target? (It should be similar to wasm which I saw was supported).

In particular, in getting the secp256k1 library to compile, this was helpful to add to the build.rs

 if env::var("CARGO_CFG_TARGET_ARCH").unwrap() == "riscv32" {
    const DEFAULT_RISCV_GNU_TOOLCHAIN: &str = "/opt/riscv";
    println!("cargo:rerun-if-env-changed=RISCV_GNU_TOOLCHAIN");
    let riscv_gnu_toolchain_path = env::var("RISCV_GNU_TOOLCHAIN").unwrap_or_else(|_| {
            DEFAULT_RISCV_GNU_TOOLCHAIN.into()
        });
  base_config
              .compiler("clang")
              .no_default_flags(true)
              .flag(&format!("--sysroot={riscv_gnu_toolchain_path}/riscv32-unknown-elf"))
              .flag(&format!("--gcc-toolchain={riscv_gnu_toolchain_path}"))
              .flag("--target=riscv32-unknown-none-elf")
              .flag("-march=rv32im")
              .flag("-mabi=ilp32")
              .flag("-mcmodel=medany")
              .flag("-Os")
              .flag("-fdata-sections")
              .flag("-ffunction-sections")
              .flag("-flto")
              .target("riscv32-unknown-none-elf");
}

so maybe something like that in this case would be helpful here too?

[mratsim]

Note that the compiler path depends on the Linux (or MacOS or Windows) distribution method, and it's likely better to assume that it's in the path rather than in /opt.

[dot-asm]

It should be noted that it's perfectly possible to compile blst without C headers with contemporary gcc or clang. This means that you don't have to bother with --sysroot or anything of the sort. All you need is to pass -ffreestanding to a compiler [recognized by cc-rs] that can generate RISC-V ELF object modules. And the best part is that blst's build.rs does it for you already (last adjusted in 2899b7f). So the only question left is if cc-rs can spot a suitable compiler, and if [it] doesn't on your system, you'd be expected to direct it to one. Easiest is to set the CC environment variable to clang. This is because the majority of clang installations are capable of generating RISC-V object modules, Linux, homebrew, Windows, including one provided by Microsoft as a Visual Studio option... With this in mind the question is rather what is it that doesn't work (past 2899b7f) for you. I mean do tell.

[dot-asm]

Easiest is to set the CC environment variable to clang.

Just in case for reference. In the essence we're talking about "bare-metal" Rust targets here, right? At least that's primarily where -ffreestanding flag is passed. Since it's a known fact that Rust uses "own" linker on "bare-metal" platforms, rust-lld, one can make a case that it would be more appropriate than not to default to clang. On the grounds that both rust-lld and clang are llvm-based. But even in this case it would be hardly appropriate to force it. I mean one can advocate for "if the target is "bare-metal" and CC is not set, see if clang is available on the $PATH and choose it," but not for "choose clang on "bare-metal" platforms unconditionally."

[dot-asm]

And the best part is that blst's build.rs does it for you already (last adjusted in 2899b7f).

To clarify, it's assumed that the commit in question should cover your target. At least it does cover riscv32im-risc0-zkvm-elf.

[dot-asm]

For public reference, it was confirmed that the issue is resolved by the referred commit, and by extension in latest version, "out of band."