go_shared_library

[sluongng]

So we have had a few posts complaining about go_test binary sizes recently, especially in remote_cache + RBE context.
One obvious solution is what we are cooking in remote-apis repo, where we attempt to apply Content Defined Chunking to those binaries.
But that solution would take a while to roll out to different cache/rbe server implementations and Bazel.

I was thinking that we could offer folks a second solution: dynamically link the go test binaries.
The idea is to introduce a go_shared_library rule which works something like this (rough poc)

go_shared_library(
    name = "sharedlib_shared",
    srcs = ["sharedlib.go"],
    importpath = "github.com/bazelbuild/rules_go/tests/core/linkshared/sharedlib",
    target_compatible_with = ["@platforms//os:linux"],
)

go_test(
    name = "sharedlib_test",
    srcs = ["sharedlib_test.go"],
    linkshared = "on",
    shared_deps = [":sharedlib_shared"],
    target_compatible_with = ["@platforms//os:linux"],
    deps = [":sharedlib_shared"],
)

This is similar to cc_shared_library where the library will be linked as an .so file and later-on dynamically linkable to the test binary.
Underneath, this uses cmd/link -linkshared flag to link the final binary.

With this, monorepo can carve out multi-part binaries (the dynamically linked binary with several .so shared libs) for better cache hits, in RBE or in a container image layout

[sluongng]

de148a3

rough vibe code Poc

[sluongng]

https://bazelbuild.slack.com/archives/CDBP88Z0D/p1769525438580289
https://bazelbuild.slack.com/archives/CA31HN1T3/p1770152332649749

a few Slack threads on this topic. We know a few other enterprise users who are experiencing similar issues.

[mkosiba]

We have a few repos that are affected by this. Some of them are pretty large and refactoring the codebase to work around this is very unlikely to happen, so having the ability to more explicitly share code across tests would be very useful.

[jayconrod]

Go already has -buildmode=shared. It looks like we don't support that through the linkmode attribute, though we do support some other modes.

This is extremely difficult to support in practice though and is soft-deprecated in Go. I think it would probably work for this specific case, but I wouldn't want to support it in rules_go in general.

[sluongng]

Go already has -buildmode=shared. It looks like we don't support that through the linkmode attribute, though we do support some other modes.

Yeah. That's what I wanted to do with go_shared_library, it's essentially using shared buildmode and link the .so.

Then the test binary consumes the .so with -linkshared.

This is extremely difficult to support in practice though and is soft-deprecated in Go.

Would love to read more about this.
Do you know if the Go team is planning for some kind of alternatives?
The big binary size issue is quite obvious in big monorepos with a lot of dependencies.

[jayconrod]

I don't think the Go team wrote much if anything publicly about the build modes. There are basically two problems, both stemming from .so files from one build being used in a different build in the future.

1. Go doesn't have a stable ABI, so binaries may not be compatible over time. I'm not sure it's even stable across patch releases.
2. All transitively imported packages must be compiled with the same module versions and with expected export data. (Note that inlineable functions are serialized into the export data, so it's sensitive to small changes even in some function bodies).

If go_shared_library were used as you suggest here, Bazel could guarantee these conditions are satisfied. But I think if go_shared_library were available, it would be widely used in ways that aren't safe, and I'd expect a lot of bug reports.

[fmeum]

Perhaps we could follow the design of cc_shared_library but in even stricter form: go_shared_library wouldn't advertise any default output files on its own, but would propagate a shared library together with the info of all the contained targets to go_test targets that depend on it via a custom provider.