Repository navigation
[BUG] Fail to build with -Werror on macOS. #2263
Description
Describe the bug
Compile warnings on macOS. Breaks build of BoringSSL because that one uses -Werror in its own cxxopts.
System
Which OS, compiler, and compiler version are you using:
- OS: macOS 26.5.2
- Compiler and version: Apple clang version 21.0.0 (clang-2100.1.1.101); Target: arm64-apple-darwin25.5.0; Thread model: posix
To reproduce
Steps to reproduce the behavior:
- sync to commit
8b66b54f7e1bf6b25390dca1dea3f18a40e607f9 bazel build --cxxopt=-Werror :all(or even justbazel build :all)- See error (or multiple screen pages of warning spam)
Actual behavior
INFO: Analyzed 3 targets (0 packages loaded, 627 targets configured).
ERROR: /private/tmp/benchmark/BUILD.bazel:41:11: Compiling src/benchmark_runner.cc failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //:benchmark) external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object ... (remaining 43 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from src/benchmark_runner.cc:15:
In file included from src/benchmark_runner.h:23:
In file included from src/perf_counters.h:30:
src/mutex.h:79:40: error: mutex 'mut_' is still held at the end of function [-Werror,-Wthread-safety-analysis]
79 | void lock() ACQUIRE() { mut_.lock(); }
| ^
src/mutex.h:79:32: note: mutex acquired here
79 | void lock() ACQUIRE() { mut_.lock(); }
| ^
src/mutex.h:80:34: error: releasing mutex 'mut_' that was not held [-Werror,-Wthread-safety-analysis]
80 | void unlock() RELEASE() { mut_.unlock(); }
| ^
2 errors generated.
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.202s, Critical Path: 1.00s
INFO: 14 processes: 1 action cache hit, 9 internal, 5 darwin-sandbox.
ERROR: Build did NOT complete successfully
Expected behavior
A working build.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Can workaround by also passing --cxxopt=-DHAVE_THREAD_SAFETY_ATTRIBUTES=1. Suggest adding this to your BUILD.bazel. Does Bazel even work with any compilers that don't support thread safety attributes?
Our workaround: https://boringssl-review.googlesource.com/c/boringssl/+/99447
Activity
LebedevRI commentedon Jul 23, 2026
Are you enabling
-Wthread-safety-analysisfor the library build?That isn't something that can just be turned on, as you've discovered.
I'm not sure what the state of the art is with those annotations,
but certainly, one needs to at least also pass that define.
divVerent commentedon Jul 23, 2026
I was not using any flags whatsoever, merely
bazel build :all.The problem might be specific to macOS.
divVerent commentedon Jul 23, 2026
In
bazel aquery :all, I do see-Wthread-safety. I didn't add it though.The config is
darwin_arm64-fastbuild, and I got bazelisk from Homebrew.Seems Bazel indeed wants to enable it by default if available: https://github.com/bazelbuild/rules_cc/blob/edc6a8d7227d76d798ac4041efc8fdacee9d5fd7/cc/private/toolchain/unix_cc_configure.bzl#L663
On Linux it passes
-Wthread-safetytoo, but it doesn't warn for Google Benchmark. Something's different about Apple's Clang.LebedevRI commentedon Jul 23, 2026
(I'm guessing the fact that libc++ is the default on Apple.)
divVerent commentedon Jul 24, 2026
Also, I realized that GCC (at least in Debian Stable's version) doesn't support these annotations, so it's not as simple as just always enabling them.
Maybe we need automatic feature detection e.g. via __has_attribute instead? As IIRC in Bazel we can't do any "conftest" builds.
Something along the lines of:
would allow one still be able to specify
-DHAVE_THREAD_SAFETY_ATTRIBUTES=0to override. (Not 100% sure if capability implies all the others though)Detect thread safety attribute support in mutex.h (google#2263)
Enable thread safety attributes when compiling with clang (google#2263)
Enable thread safety attributes when compiling with clang (google#2263)
Define HAVE_THREAD_SAFETY_ATTRIBUTES from the Bazel build instead
Always enable thread safety attributes for clang (#2263) (#2275)
LebedevRI commentedon Sep 15, 2026
Fixed in #2275.