bazelbuild
Put absolute paths into -extldflags
Bug fix
The go build system stores information about build flags (and environment variables) in the _go_.o file (go package manifest). When you use cgo, data from "CGO_LDFLAGS" is added to this file as is and used during final binary linking. If you add absolute path to "CGO_LDFLAGS" environment, it will be save inside manifest too. However, when using a distributed build system such as BuildBarn, different build agents not share all paths (such as "bazel sandboxing" paths). If the _go_.o file inside go library contains non-existent paths, linking with this module fails.
This patch puts all flags with absolute paths into -extldflags. In this case its not stored in the go package manifest.
Problem can be reproduced only on specific cases (we use custom sysroot and distributed build system) so I don't know how to write good "common" test.
Could you post examples of the paths that cause cache misses? I would like to understand why this hasn't come up before.
Before reviewing this, I think we need a clearer description of the problem being solved. Please open an issue explaining that and link here.
What are the absolute paths coming in through cgo? Why is that happening?
I suspect that the Go builder and the linker may be the wrong place to fix this. Maybe we can avoid absolute paths in the first place.
I was unable to quickly reproduce the issue using the actual opensource tools (in our repository we use self-built compiler and sysroot). The original issue in our build occurred on an older version of basel and a different configuration of the buildbarn server (few months ago). I was too lazy to creating pool request immediately, which I now regret) Currently, when disabling the patch in our repository, the issue appears similar to https://github.com/bazel-contrib/rules_go/issues/4091. Also we are still using the old LLVM 16 infrastructure (Clang, LLD). Maybe that is the one of causes. I will check if the issue persists on the latest version of rules_go. If it does, I will open the issue, send reproducer and create a new pull request. For now, this pull request can probably be closed. Thanks for your time.