Open philbinj opened 2 months ago
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?
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:
What did you expect to see?
Correct compilation
What did you see instead?
Error message shown above