[Bug]: Build failures on OSX with bazel upgrade to 8.0.0

[monkeynova]

Describe the issue

Recently bazelisk has upgraded the default bazel version to 8.0.0. When bazelisk started to use this version, I've started to get failures building abseil-cpp due to missing dependencies for standard c++ headers. As an example I get

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging external/abseil-cpp+/absl/debugging/internal/utf8_for_code_point.cc:17:10: error: module abseil-cpp+//absl/debugging:utf8_for_code_point does not depend on a module exporting 'cstdint' 17 | #include <cstdint> | ^ 1 error generated.

Forcing an earlier bazel version with USE_BAZEL_VERSION=7.4.0 successfully builds abseil, and setting it back to 8.0.0 correspondingly causes the failures to return.

Steps to reproduce the problem

In my repo, which includes the following in MODULES.bazel (which I believe is latest in the bcr).

bazel_dep(name = "abseil-cpp", version = "20240722.0.bcr.2")

USE_BAZEL_VERSION=8.0.0 bazelisk test ...

What version of Abseil are you using?

20240722.0.bcr.2

What operating system and version are you using?

`# uname -a

Darwin Mac.localdomain 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:02:45 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8112 arm64`

What compiler and version are you using?

`# gcc -v

Apple clang version 16.0.0 (clang-1600.0.26.6)

Target: arm64-apple-darwin24.1.0

Thread model: posix

InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin`

What build system are you using?

See earlier description. 7.4.0 works; 8.0.0 doesn't

Additional context

There's a variety of errors about cstdint or other standard headers (included through <>) depending on which compile fails first.

[derekmauro]

I think your toolchain probably isn't configured correctly. utf8_for_code_point.cc contains #include <cstdint>. Something either in Bazel or Clang probably broke the undeclared dependency on the standard library, maybe because auto-configuration of standard library detection has changed or broke. Our CI uses this line

abseil-cpp/ci/linux_clang-latest_libcxx_bazel.sh

Line 75 in 51b7426

-e CPLUS_INCLUDE_PATH="/opt/llvm/libcxx/include/c++/v1" \

to workaround this issue when we have a custom built toolchain installed.

[monkeynova]

I believe I am using the default cc toolchain. This is my MODULE.bazel file, and you should be able to look at neighboring files if you need to look at something different.

I'll look into whether or not I can affect the behavior with that environment variable.

[monkeynova]

Setting that environment variable to the location of the installed c++ headers didn't change the results.

I've tried running keith@Mac:~/github/advent-of-code $ bazel aquery @abseil-cpp//absl/base:log_severity on both bazel 7.4.0 and bazel 8.0.0 and I'm not seeing significant changes. I dug into the included module-map file that was being used by 8.0.0 and while I'm not familiar with the details of this file format it looked like the right sort of things where clang should have been aware of the system header dependency.

[monkeynova]

I also updated the title to reflect that I've only been able to replicate the problem on OSX so far. My linux+gcc build is OK.

[monkeynova]

I downloaded abseil and I don't have problems with "bazel test ...". Digging into a single build with sandbox_debug I see that the successful abseil build uses a module map that includes files like

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/atomic

While my unsuccessful build includes files like

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/atomic

Both of these files exist, but I appear to be getting the system map configuration wrong. I'm still not sure what I'm doing incorrectly around the toolchain, but I'll keep digging...

[monkeynova]

I tried to reproduce this problem in other repos I have using abseil. I was unable to do so.

I tried bazel clean which didn't fix my problem, but bazel clean --expunge did.