go: Duplicated definitions error

[asteurer]

When I'm building a wasm application that make use of multiple SDKs using wit-bindgen Go bindings, I get the following error when running the go build command:

Error: 'go build' command failed: # github.com/calebschoepp/opentelemetry-wasi/examples/spin-basic
link: duplicated definition of symbol cabi_realloc, from github.com/spinframework/spin-go-sdk/v3/wit_component/wit_runtime (type STEXT size 2) and github.com/calebschoepp/opentelemetry-wasi/wit_component/wit_runtime (type STEXT size 2)

Error: Build command for component go-spin-basic failed with status Exited(1)

This is due to the wit_component/wit_runtime -> cabiRealloc function being implemented multiple times. My current workaround is to remove it from one of the SDK implementations.

I'm wondering if there is a fix or if there's a workaround that wouldn't require users to alter the source code of an imported SDK?

[asteurer]

@dicej

[dicej]

Thanks for reporting this, @asteurer. This is what we were discussing here. I believe the solution will be to publish the wit_runtime, wit_async, etc. packages as part of a reusable Go module somewhere and reference that module as a dependency rather than emit them as part of the generated bindings. We could either add such a module to this repo or create a new repo for it; not sure which is better.

[asteurer]

I spent some time with this, and my preference is to have the module live in wit-bindgen. This is an example of what a generated wit_component module could look like:

module wit_component

go 1.25.5

replace github.com/bytecodealliance/wit-bindgen => github.com/bytecodealliance/wit-bindgen/crates/go/src/package

The imports would look something like this:

import (
    "github.com/bytecodealliance/wit-bindgen/wit_runtime"
    "github.com/bytecodealliance/wit-bindgen/wit_async"
    "github.com/bytecodealliance/wit-bindgen/wit_types"
)

There are also generated types (e.g. Tuple2) that would need to be packaged differently:

import (
    "wit_component/local_wit_types"
)

@dicej Let me know if there are any concerns with this approach.

[dicej]

@asteurer Thanks for digging in to this. That sounds reasonable to me.

Regarding the TupleN types: we could consider defining them in wit_types for all "reasonable" values of N, e.g. 2-16 and either fall back to generating local_wit_types for values of N greater than 16 or just raise an error in that (unlikely) case. Otherwise, we run the risk of multiple incompatible versions of a given TupleN type being generated across multiple SDKs.