Wasmtime GitHub notifications bot (Sep 11 2025 at 18:13): Wasmtime GitHub notifications bot (Sep 11 2025 at 18:13):simongdavies opened issue #11685:
We are embedding wasmtime in hyperlight-wasm. We do not support being able to compile wasm in hyperlight-wasm so we compile to cwasm offline and load those compiled versions at runtime.
This creates a problem when we want to upgrade from one version of wasmtime to another in that we need to create and keep/distribute a cwasm version for each version of wasmtime that is in use.
We had hoped to be able to use LTS versions of wasmtime to reduce the need to recompile but it would seem that LTS versions have the same behaviour as other versions in this regard.
Is this intentional?
Is it something that would be open to changing?The following demonstrates this issue:
wasmtime --version wasmtime 36.0.1 wasmtime run --invoke add add.wasm 1 2 warning: using `--invoke` with a function that takes arguments is experimental and may break in the future warning: using `--invoke` with a function that returns values is experimental and may break in the future 3 wasmtime compile add.wasm wasmtime run --invoke add --allow-precompiled add.cwasm 1 2 warning: using `--invoke` with a function that takes arguments is experimental and may break in the future warning: using `--invoke` with a function that returns values is experimental and may break in the future 3 cargo install wasmtime-cli --locked --version 36.0.2 wasmtime run --invoke add --allow-precompiled add.cwasm 1 2 Error: failed deserialization for: add.cwasm Caused by: Module was compiled with incompatible Wasmtime version '36.0.1'
Wasmtime GitHub notifications bot (Sep 11 2025 at 18:49):alexcrichton commented on issue #11685:
This is intentional insofar as we bake the version string into cwasms and ensure that the loaded version string matches. It's less intentional in the sense that this decision was made in the context of major versions of wasmtime, not patch versions. In that sense I'd personally agree that this is probably a guarantee that we should provide. I'll look to make a PR, thanks for opening the issue!
Wasmtime GitHub notifications bot (Sep 11 2025 at 18:54):bjorn3 commented on issue #11685:
Allowing this would restrict the kind of changes patch releases can make, right? And if the patch is on the Cranelift side, then you necessarily have to recompile to get the security fix.
Wasmtime GitHub notifications bot (Sep 11 2025 at 18:57):alexcrichton commented on issue #11685:
Correct yeah, and indeed if the bug is in Cranelift's output a recompile would be necessary. We also have the escape hatch of updating the version string matching manually in case a conscious break is actually needed.
Wasmtime GitHub notifications bot (Sep 18 2025 at 03:48):alexcrichton closed issue #11685:
We are embedding wasmtime in hyperlight-wasm. We do not support being able to compile wasm in hyperlight-wasm so we compile to cwasm offline and load those compiled versions at runtime.
This creates a problem when we want to upgrade from one version of wasmtime to another in that we need to create and keep/distribute a cwasm version for each version of wasmtime that is in use.
We had hoped to be able to use LTS versions of wasmtime to reduce the need to recompile but it would seem that LTS versions have the same behaviour as other versions in this regard.
Is this intentional?
Is it something that would be open to changing?The following demonstrates this issue:
wasmtime --version wasmtime 36.0.1 wasmtime run --invoke add add.wasm 1 2 warning: using `--invoke` with a function that takes arguments is experimental and may break in the future warning: using `--invoke` with a function that returns values is experimental and may break in the future 3 wasmtime compile add.wasm wasmtime run --invoke add --allow-precompiled add.cwasm 1 2 warning: using `--invoke` with a function that takes arguments is experimental and may break in the future warning: using `--invoke` with a function that returns values is experimental and may break in the future 3 cargo install wasmtime-cli --locked --version 36.0.2 wasmtime run --invoke add --allow-precompiled add.cwasm 1 2 Error: failed deserialization for: add.cwasm Caused by: Module was compiled with incompatible Wasmtime version '36.0.1'
Wasmtime GitHub notifications bot (Sep 18 2025 at 03:48):alexcrichton commented on issue #11685:
Fixed in https://github.com/bytecodealliance/wasmtime/pull/11687
Last updated: Dec 06 2025 at 06:05 UTC