chenyan2002 opened issue #14346:
When
-W component-model-canonical-namesfeature is enabled, the guest side component encodes interface names with canonical names, while the host-side bindgen is still using the full version. This causes the linking to fail.
NameMapcurrently supports matchinga:b/c@0.2.1with its alternate keya:b/c@0.2. But if the component is importinga:b/c@0.2, we cannot match it back witha:b/c@0.2.1. We need to refactorNameMap/alternate_lookup_keyto be able to handle both canonical version and full version during the transition period.Another fix is to add an option in the host side
wit-bindgento emit canonical names. But when the component is importing a full version,NameMapneeds to know how to match it with the canonical name.Raised from https://github.com/bytecodealliance/wasmtime/pull/14344#discussion_r4019873593
alexcrichton added the wasm-proposal:component-model label to Issue #14346.
alexcrichton commented on issue #14346:
I haven't sat down to think through a full solution just yet, but the main property I think that should be upheld is that turning on and/or rolling out canonical names should not break any preexisting behaviors. For example turning on the CLI feature shouldn't cause any existing workflows to break. Additionally if this were a
bindgen!feature then turning that on inwasmtime-wasishouldn't cause any existing workflows to break. I think it's fine if the way this is configured opts-in to more behaviors or perhaps disallows some pretty edge-case-y behaviors but for big things like "instantiating a preexisting component using WASI not using canonical-names" should not break.I'd probably personally lean towards not changing insertion into a linker and leave
bindgen!dealing with full versions. Internally theNameMapwould satisfy requests for 0.2 with 0.2.1 then, for example. I haven't fully thought this through, however.
Last updated: Sep 20 2026 at 18:08 UTC