Support using multiple versions of `wasmtime` in a crate

[adampetro]

Feature

It would be beneficial to provide the ability to include multiple versions of wasmtime in a crate in order to compile modules with multiple wasmtime versions.

By using all default features excluding async, it is somewhat possible. However, it is necessary to include compiler flags like cargo:rustc-link-arg=-Wl,--allow-multiple-definition in a build script in order to get by the multiple definition errors such as:

wasmtime-runtime-8.0.1/src/debug_builtins.rs:39: multiple definition of `set_vmctx_memory'

I would like to avoid using these compiler flags if possible for a couple of reasons. First, I have had difficulty using them in a single crate in a workspace, as the individual crate can be tested and built in isolation but using workspace-level commands still yields the multiple definition errors. Additionally, there is a risk of undefined behaviour.

Benefit

Supporting multiple versions of wasmtime in the same crate can be hugely beneficial in applications that rely on caching large numbers of compiled modules, specifically for handling wasmtime version bumps. If multiple versions of wasmtime can be included in a crate, it is possible to build up the cache of compiled modules for the new version while still executing modules for the old version, and then cut over to executing with the new version seamlessly with a fully populated cache.

Implementation

A small helper crate with a small number of procedural macros could be used to add a suffix to any named entities that lead to multiple definition errors, and any references to them. The suffix could be based on the wasmtime crate version or customizable with an environment variable.

I have prepared a prototype in this commit that uses the wasmtime crate version to generate the suffix.

Potential complications

1. Because macros are evaluated at compile time, it wouldn't be compatible with ModuleVersionStrategy::Custom when the value used is generated dynamically at runtime. However, if versioned exports are opt-in then it shouldn't be a problem, it just can't be used with dynamic custom versions.
2. It would be more complicated to implement for s390x because of this file.

Alternatives

• shell out to multiple versions of wasmtime CLI to achieve multi-version compilation
• use compiler flags such as cargo:rustc-link-arg=-Wl,--allow-multiple-definition, but as mentioned above this has undesirable consequences

[alexcrichton]

Personally I think it's a good idea to strive to support this, it's generally "cleaner" to not rely on having a single version of things. That being said the implementation of this needs to be balanced with maintainability at the same time. For example if a release checklist was "go on main and update a bunch of symbols" I don't think would work well, but having something more automatic (e.g. adding a suffix as you suggest) would work well. A suffix implementation, however, is likely to be somewhat nontrivial but still not outside the realm of feasability if you're interested in tackling it.

It's worth pointing out that wasmtime-fiber "correctly" has a links which says "there can only be one copy of this". It looks like wasmtime-runtime incorrectly does not have a links. I would not recommend using cargo:rustc-link-arg=-Wl,--allow-multiple-definition as that is more likely to produce a broken binary than a working one. Duplicate symbols are not guaranteed to have the same behavior, and overwriting one with a different version would almost certainly cause the resulting binary to break.

Some places I can think of off the top of my head to handle a version suffix are:

• Any invocation of asm_func! as a macro, including those in wasmtime-fiber and crates/runtime/src/trampolines/*.rs
• As you've pointed out the external s390x assembly file (there's one for fibers as well)
• As you've pointed out, the crates/runtime/src/debug_builtins.rs file.

For all the assembly trampolines that can all be fixed by suffixing symbols with the crate's current version number. For the debug builtins I think it would be best to probably turn off that file by default and have it be opt-in, since I don't think it's really well supported anywhere today anyway.

Would you be interested in working on a scheme to suffix the assembly symbols with the crate's current version?

[adampetro]

Would you be interested in working on a scheme to suffix the assembly symbols with the crate's current version?

Yes, I'm happy to do that. I've opened draft PR #6673 to get feedback on my initial approach. Thanks!

[adampetro]

Resolved by #6673