wasmtime / issue #4631 Wasmtime cannot be compiled to `wa... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #4631 Wasmtime cannot be compiled to `wa...

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:20):

tqwewe opened issue #4631:

Attempting to build a crate to wasm32-wasi target with wasmtime as a dependency fails.

Steps to Reproduce

Create blank crate
Import wasmtime
Build to wasm32-wasi target
bash $ cargo build --target wasm32-wasi

Expected Results

It should build just fine

Actual Results

I get a build error:

❯ cargo +nightly run -p runner
   Compiling cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)
   Compiling zstd-sys v2.0.1+zstd.1.5.2
   Compiling bincode v1.3.3
   Compiling toml v0.5.9
error: failed to run custom build command for `cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)`

Caused by:
  process didn't exit successfully: `/target/debug/build/cranelift-codegen-c41799193b42c3f7/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'error when identifying target: "no supported isa found for arch `wasm32`"', /home/ari/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/1ce9e8a/cranelift/codegen/build.rs:42:53

Versions and Environment

Wasmtime commit: #1ce9e8aa

Operating system: Linux

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:20):

tqwewe labeled issue #4631:

Attempting to build a crate to wasm32-wasi target with wasmtime as a dependency fails.

Steps to Reproduce

Create blank crate
Import wasmtime
Build to wasm32-wasi target
bash $ cargo build --target wasm32-wasi

Expected Results

It should build just fine

Actual Results

I get a build error:

❯ cargo +nightly run -p runner
   Compiling cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)
   Compiling zstd-sys v2.0.1+zstd.1.5.2
   Compiling bincode v1.3.3
   Compiling toml v0.5.9
error: failed to run custom build command for `cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)`

Caused by:
  process didn't exit successfully: `/target/debug/build/cranelift-codegen-c41799193b42c3f7/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'error when identifying target: "no supported isa found for arch `wasm32`"', /home/ari/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/1ce9e8a/cranelift/codegen/build.rs:42:53

Versions and Environment

Wasmtime commit: #1ce9e8aa

Operating system: Linux

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:32):

bjorn3 commented on issue #4631:

Wasmtime is a wasm runtime with a jit backend. It can't run on wasm as wasm doesn't support jit's. Why do you want to compile wasmtime to wasm?

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:34):

tqwewe commented on issue #4631:

I'm writing rust code which will be run with lunatic runtime. Lunatic runtime executes wasm modules. Though I want to also have my own wasmtime engine within my wasm module if that makes sense, since I don't have access to the host lunatic's engine and wasm stores

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:34):

tqwewe edited a comment on issue #4631:

I'm writing rust code which will be run with lunatic runtime. Lunatic runtime executes wasm modules. Though I want to also have my own wasmtime engine within my wasm module if that makes sense, since I don't have access to the host lunatic's engine and wasm stores

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:37):

bjorn3 commented on issue #4631:

You will need to either use a wasm interpreter (at the cost of slower execution) or extend lunatic to provide a way to compile and run arbitrary wasm modules from within it.

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:38):

tqwewe commented on issue #4631:

I see, having wasmtime running from within a wasm module simply isn't possible without a wasm interpreter?

Wasmtime GitHub notifications bot (Aug 06 2022 at 12:45):

bjorn3 commented on issue #4631:

No, wasmtime only has a jit backend (cranelift), which can't possibly work in wasm. The whole security design of wasm depends on the fact that wasm modules can't generate arbitrary native code and then execute it.

Wasmtime GitHub notifications bot (Aug 06 2022 at 16:01):

jornfranke commented on issue #4631:

Would it be possible that a WASM module can (dynamically) load another WASM module then? Maybe a stripped down version of wasmtime?
E.g. I have a system that provides various plugins and I only want to load the ones that I needed for a given file type.

The system itself is an application compiled to WASM and the plugins are dedicated WASM modules that are dynamically loaded. Would this be eventually possible? Similar to this one: https://github.com/ZuInnoTe/rust-wasm-dynamic-module-study

Or does the system always have to be "native", ie a native application loading the wasmtime runtime or a Javascript "glue" code in a browser?

Wasmtime GitHub notifications bot (Aug 06 2022 at 16:03):

jornfranke edited a comment on issue #4631:

Would it be possible that a WASM module can (dynamically) load another WASM module then? Maybe a stripped down version of wasmtime?
E.g. I have a system that provides various plugins and I only want to load the ones that I needed for a given file type.

The system itself is an application compiled to WASM and the plugins are dedicated WASM modules that are dynamically loaded. Would this be eventually possible? Similar to this one: https://github.com/ZuInnoTe/rust-wasm-dynamic-module-study (edit: or simpler, would it be possible to compile such an application to wasm32-wasi? https://github.com/bytecodealliance/wasmtime/blob/main/examples/linking.rs)

Or does the system always have to be "native", ie a native application loading the wasmtime runtime or a Javascript "glue" code in a browser?

Wasmtime GitHub notifications bot (Aug 06 2022 at 16:07):

bjorn3 commented on issue #4631:

Would it be possible that a WASM module can (dynamically) load another WASM module then?

That is what I mean with

or extend lunatic to provide a way to compile and run arbitrary wasm modules from within it.

It should then be possible to re-implement the wasmtime api based on this api exported to the wasm module.

Wasmtime GitHub notifications bot (Aug 08 2022 at 15:36):

alexcrichton commented on issue #4631:

Wasmtime indeed does not compile to wasm32-wasi and to do so would be a very large effort. The only way Wasmtime could run WebAssembly within WebAssembly would be an interpreter but that probably isn't what you want. Instead the better solution here is to probably integrate with the existing host runtime to somehow allow dynamic loading of wasm modules. That itself is no small ask though and is also quite tricky.

Otherwise there are a number of interpreters for wasm written in Rust and Wasmtime doesn't currently have an interpreter. That's a major implementation project for Wasmtime that's best discussed through RFCs, so I'm going to close this for now.

Wasmtime GitHub notifications bot (Aug 08 2022 at 15:36):

alexcrichton closed issue #4631:

Attempting to build a crate to wasm32-wasi target with wasmtime as a dependency fails.

Steps to Reproduce

Create blank crate
Import wasmtime
Build to wasm32-wasi target
bash $ cargo build --target wasm32-wasi

Expected Results

It should build just fine

Actual Results

I get a build error:

❯ cargo +nightly run -p runner
   Compiling cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)
   Compiling zstd-sys v2.0.1+zstd.1.5.2
   Compiling bincode v1.3.3
   Compiling toml v0.5.9
error: failed to run custom build command for `cranelift-codegen v0.88.0 (https://github.com/bytecodealliance/wasmtime.git#1ce9e8aa)`

Caused by:
  process didn't exit successfully: `/target/debug/build/cranelift-codegen-c41799193b42c3f7/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'error when identifying target: "no supported isa found for arch `wasm32`"', /home/ari/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/1ce9e8a/cranelift/codegen/build.rs:42:53

Versions and Environment

Wasmtime commit: #1ce9e8aa

Operating system: Linux

Wasmtime GitHub notifications bot (Aug 08 2022 at 17:29):

jornfranke commented on issue #4631:

makes sense, thanks for the answer

Instead the better solution here is to probably integrate with the existing host runtime to somehow allow dynamic loading of wasm modules

Find here some of those considerations: https://github.com/ZuInnoTe/rust-wasm-dynamic-module-study

Last updated: Nov 22 2024 at 16:03 UTC