RunNogo exec format error: nogo_actual built for wrong exec platform

[psalaberria002]

Problem

nogo_actual is built for a different exec platform than the one RunNogo executes on, causing an exec format error at build time.

Root cause

go_context_data declares the nogo attribute with cfg = "exec", which resolves the exec platform from --extra_execution_platforms ordering. The Go toolchain's RunNogo action independently resolves its exec platform via exec_compatible_with on the registered toolchain. When these two disagree, the nogo_actual binary is unusable on the exec platform where RunNogo actually runs.

Reproduction

• macOS host (darwin/arm64)
• --extra_execution_platforms=//:linux_amd64,//:default_host_platform
• The darwin Go SDK toolchain has exec_compatible_with = [darwin, arm64], so RunNogo runs on darwin
• cfg = "exec" on the nogo attribute picks linux_amd64 (first in the list), so nogo_actual is a linux/amd64 binary

Error

nogo: fork/exec .../nogo_actual: exec format error
# Execution platform: //:default_host_platform

Expected behaviour

nogo_actual should be built for the same exec platform that RunNogo will execute on.

Possible fix

When applying this patch it seems to work. Would this be the right solution?

diff --git go/private/context.bzl go/private/context.bzl
index 64758f8..06c361d 100644
--- go/private/context.bzl
+++ go/private/context.bzl
@@ -46,6 +46,7 @@ load(
 )
 load(
     "//go/private/rules:transition.bzl",
+    "go_tool_transition",
     "non_request_nogo_transition",
     "request_nogo_transition",
 )
@@ -693,7 +694,7 @@ def _go_context_data_impl(ctx):
     providers = [
         GoContextInfo(
             coverdata = ctx.attr.coverdata[0][GoArchive],
-            nogo = ctx.attr.nogo[DefaultInfo].files_to_run,
+            nogo = ctx.attr.nogo[0][DefaultInfo].files_to_run,
         ),
         ctx.attr.stdlib[GoStdLib],
         ctx.attr.go_config[GoConfigInfo],
@@ -717,7 +718,7 @@ go_context_data = rule(
         ),
         "nogo": attr.label(
             mandatory = True,
-            cfg = "exec",
+            cfg = go_tool_transition,
         ),
         "stdlib": attr.label(
             mandatory = True,

[fmeum]

I think that the right solution is to make nogo a direct implicit dep of all Go rules, not via the go_context_data indirection. That already helped fix a similar issue that affected the c++ toolchain for cgo.

Would you be willing to send a PR?

[psalaberria002]

I think that the right solution is to make nogo a direct implicit dep of all Go rules, not via the go_context_data indirection. That already helped fix a similar issue that affected the c++ toolchain for cgo.

Would you be willing to send a PR?

I will try to get some time for this next week. Do you have an example where this is done? Perhaps a link to the PR you are referring to?

[fmeum]

#4439 was that PR. This made the change for a toolchain, but moving the implicit dep in the same way should be good enough here.

[sitaktif]

I pushed a repro in https://github.com/sitaktif/rules_go/tree/rules-go-exec-format-error-repro in case that helps.

@fmeum do you think a similar fix is appropriate for the similar go-protoc-bin issue mentioned here?

[fmeum]

Fixing go-protoc may be more difficult as it probably requires dropping the go_proto_compiler intermediate rule.

[sitaktif]

I think that the right solution is to make nogo a direct implicit dep of all Go rules, not via the go_context_data indirection. That already helped fix a similar issue that affected the c++ toolchain for cgo.

Would you be willing to send a PR?

@fmeum attempted this fix in #4611

I confirmed it solves the issue for our use case; @psalaberria002 could you check if it fixes yours?

[psalaberria002]

I think that the right solution is to make nogo a direct implicit dep of all Go rules, not via the go_context_data indirection. That already helped fix a similar issue that affected the c++ toolchain for cgo.
Would you be willing to send a PR?

@fmeum attempted this fix in #4611

I confirmed it solves the issue for our use case; @psalaberria002 could you check if it fixes yours?

It does solve the nogo issue we were seeing, yes.