google / google/fleetbench

Bazel invokes `external/local_config_cc/None` as the linker

Open
#10 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
150
Forks
25
PR merge metrics
No merged PRs in 30d

Description

... if binutils not installed.

Note: This is not necessarily a fleetbench issue, but I want to at least document this here as I know others have hit similar issues, and it was a bit nasty to undo because it required knowing that you had to delete `~/.cache/bazel` in order to get it working again once in the bad state. Ideally though, this scenario would work.

Context: I'm putting together a docker container with only a clang toolchain in it for the purposes of testing that toolchain, and I want to make sure there is no chance another toolchain is being picked up. If I build with `--config=opt --config=clang` and Clang/LLD in the $PATH, I get the following confusing error:

```
ERROR: /root/.cache/bazel/_bazel_root/9c087a2e32e91c2e0a08651c5d06d7a5/external/com_google_absl/absl/random/internal/BUILD.bazel:267:11: Linking external/com_google_absl/absl/random/internal/libplatform.a failed: (Exit 1): None failed: error executing command (from target @com_google_absl//absl/random/internal:platform)
(cd /root/.cache/bazel/_bazel_root/9c087a2e32e91c2e0a08651c5d06d7a5/sandbox/linux-sandbox/328/execroot/com_google_fleetbench && \
exec env - \
PATH=/home/fleetbench/../compiler/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
PWD=/proc/self/cwd \
external/local_config_cc/None @bazel-out/aarch64-fastbuild-clang/bin/external/com_google_absl/absl/random/internal/libplatform.a-2.params)
```

That is, bazel appears to be is invoking `external/local_config_cc/None` which is not a valid path.

Furthermore, the error persists even after installing binutils, and even after a `bazel clean`. Removing the bazel cache directory or changing the bazel version does however allow the build to succeed once binutils is installed.

I found also that what seems to be going wrong is that it is checking for the presence of /usr/bin/ld.gold and hardcoding -fuse-ld=/usr/bin/ld.gold, even though that linker is ultimately unused, though I did also need to pass `--linkopt=-fuse-ld=lld`.

Supplying `--features=thin_lto` also did not work but supplying `--{c,cxx,link}opt=-flto=thin` along with `-fuse-ld=lld` did work.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.