nogo: compilation/link of `nogo_actual` only works in certain configurations

[moribellamy]

it seems that bazel is building nogo_actual at runtime. the binary is responsible for running analyzers against user code for linting.

https://github.com/bazel-contrib/rules_go/blob/b17435b816b36e9776e73879e973a148d15f82f5/go/private/rules/nogo.bzl#L113

the construction of this binary, among other things, drops whether or not the current execution has static linkage. this is a problem for builds which only work on static linkage.

for example: a common strategy for building against CGO is to cross-compile a statically linked binary with musl-c. my CI runner was happily doing this, until i tried to run nogo, at which point the resulting nogo_actual binary linked against a non-existent /lib/ld-musl-x86_64.so.1

discussion: https://bazelbuild.slack.com/archives/CDBP88Z0D/p1750086489848049

workaround:

diff --git a/go/private/rules/transition.bzl b/go/private/rules/transition.bzl
--- a/go/private/rules/transition.bzl
+++ b/go/private/rules/transition.bzl
@@ -185,12 +185,10 @@
 )
 
 _common_reset_transition_dict = dict({
     "//go/private:request_nogo": False,
-    "//go/config:static": False,
     "//go/config:msan": False,
     "//go/config:race": False,
-    "//go/config:pure": False,
     "//go/config:debug": False,
     "//go/config:linkmode": LINKMODE_NORMAL,
     "//go/config:tags": [],
     "//go/config:pgoprofile": Label("//go/config:empty"),

single_version_override(
    module_name = "rules_go",
    patch_strip = 1,
    patches = [
        "//third_party/rules_go:foobar.patch",
    ],
    version = "0.55.1",
)

to repro, we may need

bazel_dep(name = "toolchains_musl", version = "0.1.20", dev_dependency = True)

[fmeum]

Thanks for the report, that's a valid case for dropping pure and static from go_tool_transition (but not from the other transitions). Would you be willing to send a PR?

[moribellamy]

i can keep #4379 open as a reference. but @fmeum advises that a more wholistic approach is required:

https://github.com/bazel-contrib/rules_go/pull/4379#issuecomment-2990710708

the propagation of options is more appropriate for "tool" targets (such as nogo) as opposed to non-tool targets.

the workaround seems to work for me without issue at the moment. @fmeum would you be able to comment on if you forsee any gotchas with the workaround?

[fmeum]

@moribellamy No correctness gotchas, but you may end building tools such as protobuf multiple times.