Proposal: extract internal/fakecgo into a standalone shared module

[kolkov]

When two independent libraries both include internal/fakecgo (to enable runtime.cgocall with CGO_ENABLED=0), the Go linker fails with:

link: duplicated definition of symbol _cgo_init,
  from github.com/go-webgpu/goffi/internal/fakecgo (type SDATA size 8)
  and github.com/ebitengine/purego/internal/fakecgo (type SDATA size 8)

This affects any project that depends on both purego and another pure-Go FFI library (in our case, goffi). See go-webgpu/goffi#22 for the original report.

Root cause

Both packages define the same global linker symbols (_cgo_init, _cgo_thread_start, _cgo_notify_runtime_init_done, _cgo_bindm, _cgo_pthread_key_created) via //go:linkname. These names are dictated by the Go runtime - they're read by exact name during rt0_go startup. The Go linker has no dupok for data symbols and no weak symbol mechanism, so identical definitions from two packages cause a fatal error.

Both implementations are pure-Go reimplementations of src/runtime/cgo/ - neither is a copy of the other.

Current workaround

In goffi v0.4.2 we added a build tag nofakecgo so users can disable our copy:

CGO_ENABLED=0 go build -tags nofakecgo ./...

This works but requires users to know about it.

Proposal: standalone fakecgo module

The clean solution would be to extract fakecgo into a standalone public Go module under a neutral organization - not owned by purego, goffi, or any single project. Both libraries would then import _ "github.com/<neutral-org>/fakecgo", and the Go build system would deduplicate it automatically. No linker conflict, no build tags needed.

Benefits:

• Single source of truth - bug fixes and new architecture support benefit everyone
• No coordination overhead - libraries don't need to track each other's fakecgo versions
• Future-proof - any new pure-Go FFI project can import the same module

We're happy to contribute to the effort - whether that's code, testing, or CI. Would the purego maintainers be open to discussing this?

@TotallyGamerJet @hajimehoshi — would love to hear your thoughts on this. We ran into this conflict in production (go-webgpu/goffi#22) and have a build-tag workaround for now, but a shared module would be a cleaner long-term solution for the ecosystem.

[TotallyGamerJet]

Is there a reason you need your own fakecgo package?

[hajimehoshi]

вЂ

What's this?

[TotallyGamerJet]

I think it's where the em dashes used to be. Somehow they got corrupted / replaced

[kolkov]

@TotallyGamerJet Good question. goffi doesn't depend on purego - it's a standalone zero-dependency FFI library with its own ecosystem:

• gogpu - gogpu: "Pure Go Graphics Framework — GPU power, Go simplicity"
• Born - ML framework for Go with Rust Burn inspired.

So we don't need purego's fakecgo for ourselves. The problem is on the user side - when someone wants to use both purego and goffi (or libraries built on them) in the same project. For example, an ebitengine game that also uses gogpu/wgpu for compute shaders, or any project mixing purego-based and goffi-based bindings.

@zhhc99 reported this in go-webgpu/goffi#22 - could you describe your use case here? What are you building that needs both purego and goffi?

We've shipped a workaround in v0.4.2 (-tags nofakecgo), but it requires users to know about it. A shared module would make it transparent.

@hajimehoshi Sorry about the garbled character - that was a Unicode escaping issue from the GitHub GraphQL API when creating this discussion. I'll fix the body.

[kolkov]

Thanks for the response. To clarify -- we're not asking goffi to depend on purego. goffi is an independent FFI library and adding purego as a dependency doesn't make architectural sense.

The issue isn't about us -- it's about end users who want to use libraries built on both purego and goffi in the same project. For example, someone using an ebitengine-based library alongside gogpu/wgpu. They can't control which FFI library their dependencies use, and they get a linker error through no fault of their own.

Our -tags nofakecgo workaround handles this for now. If the purego team's position is that splitting out fakecgo isn't worth it, we understand -- we'll keep the build tag as the solution.

[TotallyGamerJet]

I don't understand why you don't want to rely on purego's fakecgo. You are asking us to split it out which would be depending on our fakecgo but in a different repo. This is the same outcome but more maintenance burden then just relying on purego's fakecgo which you can do right now.

[kolkov]

The difference is about what the dependency means:

• import _ "github.com/ebitengine/purego" -- an FFI library depending on a competing FFI library for a side-effect. Would ebitengine add import _ "github.com/go-webgpu/goffi/ffi" just to get fakecgo? Of course not. Same logic applies the other way.

• import _ "github.com/some-neutral-org/fakecgo" -- a shared infrastructure dependency, like golang.org/x/sys. Neither purego nor goffi owns it, both benefit from it.

That said, we've already solved the user-facing problem with -tags nofakecgo in v0.4.2. We appreciate you taking the time to discuss this.

[TotallyGamerJet]

Would ebitengine add import _ "github.com/go-webgpu/goffi/ffi" just to get fakecgo? Of course not. Same logic applies the other way.

This is not true. We are not against adding other dependencies. The reason I suggest depending on ours is because our library is used in more places and is therefore tested in more environments as well as our fakecgo supported on more platforms. Ours also turns itself off when compiled with CGO_ENABLED=1 which according to go-webgpu/goffi#13 yours does not.

import _ "github.com/some-neutral-org/fakecgo" -- a shared infrastructure dependency, like golang.org/x/sys. Neither purego nor goffi owns it, both benefit from it.

Someone needs to own the code. I don't think people will care if goffi relies on some part of purego. If anything it limits your burden from having to implement another fakecgo. That is my opinion though and I understand if you want to keep it separate.

[kolkov]

Fair points, and thanks for the thoughtful response. goffi originated from a proprietary project and has its own history -- we open-sourced it more recently but it has been powering our GPU stack for a while. We use it within our ecosystem (gogpu, born-ml, go-webgpu), and with the -tags nofakecgo workaround in v0.4.2, users who need both libraries can now use them together. That covers the practical problem.

Appreciate the discussion!