Repository navigation
[BUG] target-lexicon does not compile to riscv32 #1704
Description
Bug Report
Tried to compile wasmer inside the guest but ended up getting this error.
RISC0_DEV_MODE=1 RUST_LOG="[executor]=info" cargo run --release
Compiling methods v0.1.0 (/Users/prudhvirampey/Documents/stackrlabs/wasmX/methods)
wasm_runner: Starting build for riscv32im-risc0-zkvm-elfs(build)
wasm_runner: Compiling target-lexicon v0.12.14
wasm_runner: Compiling bytecheck v0.6.12
wasm_runner: Compiling hashbrown v0.14.3
wasm_runner: Compiling byteorder v1.5.0
wasm_runner: Compiling cranelift-codegen-shared v0.91.1
wasm_runner: Compiling parking_lot_core v0.9.9
wasm_runner: Compiling rkyv v0.7.44
wasm_runner: Compiling lock_api v0.4.11
wasm_runner: Compiling cranelift-codegen-meta v0.91.1
wasm_runner: error: failed to run custom build command for `target-lexicon v0.12.14`
wasm_runner:
wasm_runner: Caused by:
wasm_runner: process didn't exit successfully: `/Users/prudhvirampey/Documents/stackrlabs/wasmX/target/riscv-guest/release/build/target-lexicon-f7aba57ada830245/build-script-build` (exit status: 101)
wasm_runner: --- stderr
wasm_runner: thread 'main' panicked at /Users/prudhvirampey/.cargo/registry/src/index.crates.io-6f17d22bba15001f/target-lexicon-0.12.14/build.rs:52:54:
wasm_runner: Invalid target name: 'riscv32im-risc0-zkvm-elf'
wasm_runner: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
wasm_runner: warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command
Motivation
Wondering if this requires upstream target support from the devs of target-lexicon or if there could be a potential workaround in risc0?
Your Environment
- risc0-zkvm version: "0.21.0"
- Rust version: 1.76.0
- Platform/OS: mac (apple silicon)
Activity
linear commentedon Apr 23, 2024
ZKVM-415 [BUG] `target-lexicon` does not compile to riscv32
SchmErik commentedon Apr 24, 2024
Awesome! I love that project! ... but I'm not sure if it works inside the guest. So there's an open PR here: bytecodealliance/target-lexicon#96 that will add the code. I've pinged the maintainer so hopefully it will be merged/enabled soon... In the meantime you can patch your crate using the directions here: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
0xRampey commentedon Apr 24, 2024
Thanks a lot, this is very helpful.
It would be pretty cool to get wasmer running inside
risc0. It could save a lot of cycles running an AoT-compiled WASM module vs an interpreted one fromwasmi.flaub commentedon Apr 24, 2024
I think what we really want is the ability to have WASM transpile into RISC-V, which would indeed save a lot of cycles, and would be done at build time, which means we wouldn't need to get wasmer running inside the guest. This is something we've been thinking about but isn't on the near term roadmap just yet.
0xRampey commentedon Apr 30, 2024
Agreed, that would be the most efficient way to go about it.
Does this mean that the WASM needs to be compiled to a custom target like
riscv32im-risc0-zkvm-elf? There are already some runtimes like wasmer and WAMR that can compile toriscv64andriscv32targets respectively. I'd be happy to help contribute here anyway I can.flaub commentedon Apr 30, 2024
Yeah, WAMR looks really interesting!
nlok5923 commentedon May 1, 2024
Yep, This would be amazing to see if we could compile down wasm-unknownn to riscV target. But can you elaborate a bit on how it would reduce down the computation cycles ?
flaub commentedon May 1, 2024
Compared to running an interpreter, AoT should always win, assuming that it takes anywhere from 2-10 cycles for the interpreter to run a single WASM instruction.