nogo: golink uses the wrong cc linker on MacOS with DEVELOPER_DIR set

[sluongng]

What version of rules_go are you using?

v0.44.2

What version of gazelle are you using?

v0.35.0

What version of Bazel are you using?

Bazel 7

Does this issue reproduce with the latest releases of all the above?

These are the latest

What operating system and processor architecture are you using?

MacOS Intel, specifically Github Action runner macos-13

Any other potentially useful information about your toolchain?

• Default apple_support cc toolchain is disabled with --repo_env=BAZEL_NO_APPLE_CPP_TOOLCHAIN=1

• Default unix toolchain is setup normally

• Set --action_env and --host_action_env with DEVELOPER_DIR="/Library/Developer/CommandLineTools"

• Set --host_linkopt="-Wl,-v" to make ld prints out it's version.

What did you do?

bazel build //... in https://github.com/buildbuddy-io/buildbuddy

What did you expect to see?

The same ld linker under /Library/Developer/CommandLineTools is used for all actions.

For example, here is the correct linker being used for linking protoc. Note the [for tool] indicating that this is an action using exec configuration.

INFO: From Linking external/com_google_protobuf/protoc [for tool]:
@(#)PROGRAM:ld  PROJECT:dyld-1022.1
BUILD 13:20:30 Nov 10 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.8)
Library search paths:
	/usr/local/lib
Framework search paths:
ld: warning: ignoring duplicate libraries: '-lm', '-lpthread'

What did you see instead?

GoLink under nogo (in our repo the target is named vet_actual) would use a different linker than the rest https://github.com/bazelbuild/rules_go/blob/3c51b967ffaeb321634239d34d837bbfc0a17caa/go/private/rules/nogo.bzl#L134-L135

From the same build as the protoc log above would print this:

INFO: From GoLink vet_actual_/vet_actual [for tool]:
@(#)PROGRAM:ld  PROJECT:ld64-857.1
BUILD 23:13:24 May  7 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
@(#)PROGRAM:ld  PROJECT:ld64-857.1
BUILD 23:13:24 May  7 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
@(#)PROGRAM:ld  PROJECT:ld64-857.1
BUILD 23:13:24 May  7 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
	/usr/local/lib
	/Applications/Xcode_14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Applications/Xcode_14.3.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/

So for some reason, the GoLink action is setting up cgo portion of the action wrongly 🤔

[sluongng]

cc: @keith @fmeum

actual reproduction is available here buildbuddy-io/buildbuddy#5698

Note that this happens on local execution builds on the Github Action Runner, so no RBE is involved.