| commit | 20bf72d587383f2dc645f957b6ae48bfb9b33202 | [log] [tgz] |
|---|---|---|
| author | Jeremy Nimmer <jeremy.nimmer@tri.global> | Mon Feb 09 14:36:08 2026 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Mon Feb 09 14:36:45 2026 -0800 |
| tree | 779f3346679fbcdd9bde75c3ddf15fa86d248c89 | |
| parent | d81c50d0732241d07ea66e9f12982a145fb6d26d [diff] |
Fix GCC detection to be robust to symlinks Copybara Import from https://github.com/bazelbuild/rules_cc/pull/592 BEGIN_PUBLIC Fix GCC detection to be robust to symlinks (#592) On Ubuntu /usr/bin/cc is a symlink to /usr/bin/gcc. Because GCC uses `argv[0]` to report its `--version`, that means if the user has set `CC=/usr/bin/cc` then `_is_gcc` will return false and the compiler will be mis-detected. Instead of relying on the binary name, we'll match how Clang detection was already done: run with `-v` and look for the compiler species in the output. Unlike clang, we'll be slightly more careful by looking for a more specific string, and only on the last line. This is safer because `clang -v` prints GCC-adjacent details and we don't want that being detected as GCC itself. --- On Ubuntu: ``` jwnimmer@call-cps:~$ ls -l /usr/bin/cc lrwxrwxrwx 1 root root 20 Jan 31 2024 /usr/bin/cc -> /etc/alternatives/cc jwnimmer@call-cps:~$ ls -l /etc/alternatives/cc lrwxrwxrwx 1 root root 12 Jan 31 2024 /etc/alternatives/cc -> /usr/bin/gcc jwnimmer@call-cps:~$ cc --version | head -n1 cc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 jwnimmer@call-cps:~$ gcc --version | head -n1 gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 jwnimmer@call-cps:~$ cc -v 2>&1 | tail -n1 gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04) jwnimmer@call-cps:~$ gcc -v 2>&1 | tail -n1 gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04) ``` Closes #592 END_PUBLIC COPYBARA_INTEGRATE_REVIEW=https://github.com/bazelbuild/rules_cc/pull/592 from jwnimmer-tri:gcc-detection 5bc79268364947c09ae4dbd4399d9f44114c16d8 PiperOrigin-RevId: 867779427 Change-Id: I747827ca96e26ad837a1979ab717ff7a7757d683
This repository contains a Starlark implementation of C++ rules in Bazel.
The rules are being incrementally converted from their native implementations in the Bazel source tree.
For the list of C++ rules, see the Bazel documentation.
Add the following to your WORKSPACE file:
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "rules_cc", urls = ["https://github.com/bazelbuild/rules_cc/archive/refs/tags/<VERSION>.tar.gz"], sha256 = "...", )
Then, in your BUILD files, import and use the rules:
load("@rules_cc//cc:defs.bzl", "cc_library") cc_library( ... )
This repo contains an auto-detecting toolchain that expects to find tools installed on your host machine. This is non-hermetic, and may have varying behaviors depending on the versions of tools found.
There are third-party contributed hermetic toolchains you may want to investigate:
If you'd like to use the cc toolchain defined in this repo, add this to your WORKSPACE after you include rules_cc:
load("@rules_cc//cc:repositories.bzl", "rules_cc_dependencies", "rules_cc_toolchains") rules_cc_dependencies() rules_cc_toolchains()
This repository also contains migration tools that can be used to migrate your project for Bazel incompatible changes.
Script that migrates legacy crosstool fields into features (incompatible flag, tracking issue).
TLDR:
bazel run @rules_cc//tools/migration:legacy_fields_migrator -- \ --input=my_toolchain/CROSSTOOL \ --inline
Bazel and rules_cc are the work of many contributors. We appreciate your help!
To contribute, please read the contribution guidelines: CONTRIBUTING.md.
Note that the rules_cc use the GitHub issue tracker for bug reports and feature requests only. For asking questions see:
rules_cc mailing list#cc on slack.bazel.build