commit | cdd0c3cdba270115940e8ca5ec8104cbcd694671 | [log] [tgz] |
---|---|---|
author | Marcel Hlopko <hlopko@google.com> | Thu Jul 04 23:58:34 2019 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Thu Jul 04 23:59:31 2019 -0700 |
tree | 9d716ef4aa778de9a28e3a93f247973939b7348e | |
parent | 29eecb56c5f0f26b4751ec9eb79954412fb2991c [diff] |
Pass absolute path to gold when using Clang Prior to this change Bazel's C++ toolchain autoconfiguration generated toolchain that passed `-fuse-ld=gold` when gold linker was detected. After this change this will be `-fuse-ld=/usr/bin/ld.gold` or similar depending on what clang reported. Gcc will still use -fuse-ld=gold (as it doesn't accept absolute path argument to `-fuse-ld`). This is to make the Clang autogenerated toolchain not depend on PATH if we can help it. Gcc is still leaking the PATH. The leak: 1) CC is installed in a non-standard location, or is checked-in into the workspace. 2) CC is passed to Bazel's cc_configure, Bazel autoconfigures the toolchain using CC. 3) Remote worker has CC installed in the same non-standard location, or gets CC in action inputs. 4) If Host system has gold on its PATH (potentially to the surprise of the user, user might assume that since they provide CC explicitly only that installation is used), Bazel will autoconfigure the toolchain to use gold linker. 5) Remote system doesn't have gold installed, build fails. Alternative solutions: * Pass -B$(dirname $(which gcc)) to CC and pass empty PATH to all Bazel's C++ autoconfiguration commands * Do not detect gold automatically at all, require environment variable to be explicitly set to enable gold Both are backwards incompatible changes. Solution in this PR is backwards compatible. It's also not fixing the issue for Gcc. Closes #8580. PiperOrigin-RevId: 256623542
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel only rebuilds what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
See CONTRIBUTING.md
Bazel is released in ‘Beta’. See the product roadmap to learn about the path toward a stable 1.0 release.