Embedding multiple engines implementing wasm C API

[chfast]

Hi there,

Is there any practical way of building a binary containing multiple different wasm engines which all implement the WebAssembly C API?

[rossberg]

Given typical linking models, which rely on a more or less global name space for public symbols, I don't that can be done in common environments. This isn't a problem specific to this API, though, AFAIAA.

What is the use case? If it is to select one engine at runtime, could you dynamically link it?

[jakobkummerow]

As long as you're building everything from source and you're using C++, I think this could fairly easily be done by adding namespaces: include several copies of wasm.hh, wrap the first in a namespace engine1 { ... }, the second in namespace engine2 { ... }, and so on. You'll then have to make the same edit to the respective engine's implementation of the API. Anywhere else in your code you can then choose to work with, for example, engine1::wasm::Store or engine2::wasm::Store.

If your requirement is to use unmodified/prebuilt engines, then I agree with @rossberg that you can only link one implementation of any given API at a time.

[zu1k]

We have a similar problem, but our needs are more specific in that we need to use multiple engines at the same time.

It looks like the go-bindings for all engines are using cgo, which are all load-time linking. Depending on the situation it looks like we need to maintain all the engine go-bindings ourselves to implement the runtime linking. This is very tedious work, I came to see any friend who encountered a similar problem and already had a more elegant solution.