jameysharp opened issue #6717:
Steps to Reproduce
cargo run --features all-arch -- explore --target riscv64 crates/c-api/wasm-c-api/example/hello.wasmIf your native host is actually a
riscv64system, replace the target with something else such asx86_64.Expected Results
Exploration written to crates/c-api/wasm-c-api/example/hello.explore.htmlActual 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 hostVersions and Environment
Wasmtime version or commit: c34567cdddc483d6bdf6a7b04c43026174eef5bf
Operating system: Linux
Architecture: x86-64
Extra Info
Based on the error messages, apparently
wasmtime explorewinds up inEngine::check_compatible_with_native_hostby 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
Moduleis created and aModuleis "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_modulewas 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
Modulehas a good deal of useful metadata about the module thatprecompile_moduledoesn'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: Dec 13 2025 at 21:03 UTC