Unable to get io_bazel_rules_go to work with a custom c++ toolchain

[philbinj]

What version of rules_go are you using?

v0.42.0

What version of gazelle are you using?

v.0.33.0

What version of Bazel are you using?

v1.16.0

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

rules_go and gazelle are on the latest versions AFACIT. Upgrading bazel is a non-trivial effort, so i'm not sure about that one.

What operating system and processor architecture are you using?

Linux x86_64

Any other potentially useful information about your toolchain?

Custom GCC crosstool:

The crosstool calls a tools/gcc bash script that contains:
exec "external/buildroot/bin/x86_64-buildroot-linux-gnu-$(basename "${0}")" "${@}"

I.e. the actual gcc binary is contained at external/buildroot/bin/x86_64-buildroot-linux-gnu-gcc

This approach compiles and links any c++ targets without problem.

What did you do?

Trying to compile a minimal 'hello world' go_binary target fails.

It seems that cgo is unable to find the correct location for gcc and fails with the following error:

ERROR: /home/ubuntu/.cache/bazel/_bazel_ubuntu/0bc40eeeb38c5ee20e0ad3246af86ab8/external/io_bazel_rules_go/BUILD.bazel:42:7: GoStdlib external/io_bazel_rules_go/stdlib_/pkg failed: (Exit 1): builder failed: error executing command (from target @io_bazel_rules_go//:stdlib) bazel-out/k8-opt-exec-2B5CBBC6-ST-b33d65c724e6/bin/external/go_sdk/builder_reset/builder stdlib -sdk external/go_sdk -installsuffix linux_amd64 -out ... (remaining 7 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
# runtime/cgo
./toolchains/buildroot/tools/gcc: line 12: bazel-out/k8-fastbuild-ST-b33d65c724e6/bin/external/io_bazel_rules_go/stdlib_/src/runtime/cgo/external/buildroot/bin/x86_64-buildroot-linux-gnu-gcc: No such file or directory
stdlib: error running subcommand external/go_sdk/bin/go: exit status 1

What did you expect to see?

Correct compilation

What did you see instead?

Error message shown above

[fmeum]

The wrapper assumes that its current working directory is the execroot, but Go tooling and rules_go builders may change the cwd.

Could you make it so that your wrapper finds the actual gcc binary relative to its own location rather than relative to the cwd?