jameysharp opened issue #6717:
Steps to Reproduce
cargo run --features all-arch -- explore --target riscv64 crates/c-api/wasm-c-api/example/hello.wasm
If your native host is actually a
riscv64
system, replace the target with something else such asx86_64
.Expected Results
Exploration written to crates/c-api/wasm-c-api/example/hello.explore.html
Actual Results
Error: compilation settings are not compatible with the native host Caused by: target 'riscv64-unknown-unknown' specified in the configuration does not match the host
Versions and Environment
Wasmtime version or commit: c34567cdddc483d6bdf6a7b04c43026174eef5bf
Operating system: Linux
Architecture: x86-64
Extra Info
Based on the error messages, apparently
wasmtime explore
winds up inEngine::check_compatible_with_native_host
by way ofModule::from_binary
. I don't understand why this mode would use that path though.Found this together with @michelledaviest while trying to understand some profiling results.
jameysharp added the bug label to Issue #6717.
alexcrichton commented on issue #6717:
The reason for this is due to this line where a
Module
is created and aModule
is "proof of ready to run" which in a cross-compiled case is impossible since the native platform is never ready to run a different platform. Awhile back this is whyEngine::precompile_module
was added which skips "is this ready to run" checks and is suitable for cross-compilation (or enabling more features than the host has, stuff like that).The problem here though is that
Module
has a good deal of useful metadata about the module thatprecompile_module
doesn't return (it just returns aVec<u8>
). One option though would be to return-> Result<PrecompiledModule>
which packages up all the necessary information.
Last updated: Nov 22 2024 at 16:03 UTC