Bazel@HEAD doesn't build on gcc 11

[davido]

Trying to build Bazel@HEAD (009ce7b1d296e8f6b6e3d68189e6f26b47636663) is failing here with:

ERROR: /home/davido/.cache/bazel/_bazel_davido/0fa756dec521553dbe2dde6b6eac99b4/external/com_google_absl/absl/synchronization/BUILD.bazel:30:11: Compiling absl/synchronization/internal/graphcycles.cc failed: (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 31 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 31 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
external/com_google_absl/absl/synchronization/internal/graphcycles.cc: In member function 'void absl::lts_2020_02_25::synchronization_internal::GraphCycles::RemoveNode(void*)':
external/com_google_absl/absl/synchronization/internal/graphcycles.cc:451:26: error: 'numeric_limits' is not a member of 'std'
  451 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
      |                          ^~~~~~~~~~~~~~
external/com_google_absl/absl/synchronization/internal/graphcycles.cc:451:49: error: expected primary-expression before '>' token
  451 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
      |                                                 ^
external/com_google_absl/absl/synchronization/internal/graphcycles.cc:451:52: error: '::max' has not been declared; did you mean 'std::max'?
  451 |   if (x->version == std::numeric_limits<uint32_t>::max()) {
      |                                                    ^~~
      |                                                    std::max
In file included from /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/algorithm:62,
                 from external/com_google_absl/absl/synchronization/internal/graphcycles.cc:38:
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/bits/stl_algo.h:3467:5: note: 'std::max' declared here
 3467 |     max(initializer_list<_Tp> __l, _Compare __comp)
      |     ^~~
Target //src:bazel-bin-dev failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 52.484s, Critical Path: 7.30s
INFO: 75 processes: 16 internal, 59 linux-sandbox.
FAILED: Build did NOT complete successfully

Environment:

  $ gcc --version//src:bazel-bin
//src/main/cpp:client
//src/main/protobuf:command_server_cc_grpc
//third_party/grpc:grpc++_unsecure
@com_github_grpc_grpc//:grpc++_unsecure
@com_github_grpc_grpc//:gpr
@com_github_grpc_grpc//:gpr_base
@com_google_absl//absl/synchronization:synchronization
@com_google_absl//absl/synchronization:graphcycles_internal
Loading: 21 packages loaded
gcc (GCC) 11.0.0 20201204 (Red Hat 11.0.0-0)

Apparently abseil is outdated and/or is missing #include limits directive.

It seems, that Bazel itself doesn't depend on abseil, but it's rather a transitive dependency of gRPC:

  $ bazel query "somepath(src:bazel-bin, @com_google_absl//absl/synchronization:graphcycles_internal)"
//src:bazel-bin
//src/main/cpp:client
//src/main/protobuf:command_server_cc_grpc
//third_party/grpc:grpc++_unsecure
@com_github_grpc_grpc//:grpc++_unsecure
@com_github_grpc_grpc//:gpr
@com_github_grpc_grpc//:gpr_base
@com_google_absl//absl/synchronization:synchronization
@com_google_absl//absl/synchronization:graphcycles_internal
Loading: 21 packages loaded

[divanorama]

abseil-cpp probably fixed it in https://github.com/abseil/abseil-cpp/commit/5bf048b8425cc0a342e4647932de19e25ffd6ad7 grpc doesn't have this in master yet https://github.com/grpc/grpc/blob/e745f8cb558798f1c8b91baa42d46228a9d4a0c4/bazel/grpc_deps.bzl#L245

As a temporary workaround, declaring newer abseil-cpp dependency before grpc_deps() call in WORKSPACE may work (didn't test).

Haven't found issue on gcc 11 compilation in https://github.com/grpc/grpc/issues so filing one sounds like a way to go

[olekw]

Debian is tracking this as well for Debian 12. We'll make sure to include the fix once Debian 12 development opens later this year.

[hazelnusse]

This was fixed in the public abseil-cpp on October 20, 2020, probably a fair bit earlier in Google's internal repo.

There are new features I would like to test in bazel (implementation_deps is one), but I am unable to do so because of the missing #include <limits> portion of the patch mentioned above.

I tried updating distdir_deps.bzl to reference a version of abseil-cpp that has the aforementioned patch but when I do bazel build //src:bazel-dev something is still fetching an old version of abseil that does not have the patch. My branch is here in case anybody has time to see what I'm doing wrong: https://github.com/hazelnusse/bazel/tree/abseil-cpp-live-at-head

Specifically, when I build this branch, I get the following source distribution of abseil in the bazel-bazel dir:

$ ll bazel-bazel/external/com_google_absl/
total 100
drwxr-xr-x  5 luke luke  4096 Jun  9 21:32 .
drwxr-xr-x 27 luke luke  4096 Jun  9 21:32 ..
drwxr-xr-x 20 luke luke  4096 Jun  9 21:32 absl
drwxr-xr-x  2 luke luke  4096 Jun  9 21:32 ci
drwxr-xr-x  4 luke luke  4096 Jun  9 21:32 CMake
-rw-rw-r--  1 luke luke  1095 Mar  4  2020 ABSEIL_ISSUE_TEMPLATE.md
-rw-rw-r--  1 luke luke   295 Mar  4  2020 AUTHORS
-rw-rw-r--  1 luke luke    51 Mar  4  2020 .clang-format
-rw-rw-r--  1 luke luke  4568 Mar  4  2020 CMakeLists.txt
-rw-rw-r--  1 luke luke  2047 Mar  4  2020 conanfile.py
-rw-rw-r--  1 luke luke  6863 Mar  4  2020 CONTRIBUTING.md
-rw-rw-r--  1 luke luke  8801 Mar  4  2020 FAQ.md
-rw-rw-r--  1 luke luke   313 Mar  4  2020 .gitignore
-rw-rw-r--  1 luke luke 11361 Mar  4  2020 LICENSE
-rw-rw-r--  1 luke luke   770 Mar  4  2020 LTS.md
-rw-rw-r--  1 luke luke  4767 Mar  4  2020 README.md
-rw-rw-r--  1 luke luke   642 Mar  4  2020 UPGRADES.md
-rwxr-xr-x  1 luke luke    36 Jun  9 21:32 WORKSPACE

The LTS.md file has contents:

$ tail -7 bazel-bazel/external/com_google_absl/LTS.md
## LTS Branches

The following lists LTS branches and the dates on which they have been released:

* [LTS Branch December 18, 2018](https://github.com/abseil/abseil-cpp/tree/lts_2018_12_18/)
* [LTS Branch June 20, 2018](https://github.com/abseil/abseil-cpp/tree/lts_2018_06_20/)
* [LTS Branch August 8, 2019](https://github.com/abseil/abseil-cpp/tree/lts_2019_08_08/)

This indicates to me that somehow an older version of abseil-cpp is being referenced instead of the one I reference in distdir_deps.bzl on my branch.

The only other reference to abseil I can find in the bazel source tree is in the third_party/py/abseil/ files. Perhaps this can explain how I'm getting a different version of abseil than I'm specifying in distdir_deps.bzl? This references a pypi library, which at first glance does not seem to be the culprit.

The blog post about bazel LTS release seems to indicate that bazel master would follow more closely to the "live at head" philosophy, perhaps @hicksjoseph @aiuto or @philwo could comment?

[davido]

This was fixed in the public abseil-cpp on October 20, 2020 [...]

Right, this PR and this PR that bumped gRPC and abseil releases fixed all issues on gcc 11, but fail to be built on outdated platforms and gcc toolchain versions on Bazel Buildkite CI.

See these follow-up discussions what should be the right course of actions: https://github.com/bazelbuild/continuous-integration/issues/1167, https://github.com/bazelbuild/bazel/issues/13561 and this thread on bazel-discuss@ to get more feedback on this: https://groups.google.com/g/bazel-discuss/c/xXkCsFjosG8.

[Geremia]

I get these errors

src/main/java/com/google/devtools/build/lib/analysis/config/BuildOptions.java:153: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/skyframe/SkyframeBuildView.java:564: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/analysis/NoBuildEvent.java:84: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/bazel/BazelWorkspaceStatusModule.java:116: error: no suitable method found for toString(Charset)
src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryResolvedModule.java:136: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/bazel/repository/RepositoryResolvedModule.java:141: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/rules/cpp/CppModuleMapAction.java:117: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/buildtool/buildevent/BuildStartingEvent.java:109: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/remote/merkletree/DirectoryTree.java:230: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/remote/merkletree/DirectoryTree.java:236: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/rules/cpp/LibrariesToLinkCollector.java:109: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/rules/cpp/LibrariesToLinkCollector.java:187: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/runtime/commands/CleanCommand.java:212: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/runtime/commands/info/ServerPidInfoItem.java:31: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/shell/JavaSubprocessFactory.java:118: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/skyframe/ToolchainResolutionFunction.java:430: error: cannot find symbol
src/main/java/com/google/devtools/build/lib/util/SimpleLogHandler.java:371: error: cannot find symbol
src/main/java/com/google/devtools/common/options/OptionsUsage.java:59: error: cannot find symbol
src/main/java/net/starlark/java/eval/EvalUtils.java:399: error: cannot find symbol
19 errors

when building Bazel 6.0.0-pre.20211117.1, but I get davido's errors mentioned in #12702 when building Bazel 4.2.2.

[jesec]

Encountered the issue as well. I made a set of patches that resolves the issue.

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29084/diffs

To deal with GCC 11 FTBFS, you would need to pick:

• 8cc0e261a313dbf5e81bfeca2bafa3e12a991046
• a129aeb333d83a4466ac2c996b84a113405acb4d
• 9761509f9ccc3892f42425b904adf1ef10bcb1f4
• absl's 0e2c62da1dcaf6529abab952bdcc96c6de2d9506

and, the first three commits have to be incorporated into java_tools as well.

[jesec]

It would be nice to have a 4.2.3 with those changes cherry-picked.

AFAIK, the issue could completely block Bazel from working with Java projects on a system that has GCC 11 installed. edit: on platforms where there is no prebuilt ijar binary: (unfortunately that very well includes linux_arm64, which now have a rather significant user presence)

alias(
    name = "prebuilt_binary_or_cc_binary",
    actual = select({
        ":linux_x86_64": ":ijar_prebuilt_binary",
        ":darwin_x86_64": ":ijar_prebuilt_binary",
        ":darwin_arm64": ":ijar_prebuilt_binary",
        ":darwin_arm64e": ":ijar_prebuilt_binary",
        ":windows": ":ijar_prebuilt_binary",
        "//conditions:default": ":ijar_cc_binary",
    }),
)

[Geremia]

@jesec

Encountered the issue as well. I made a set of patches that resolves the issue. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29084/diffs

Thanks. Your GitLab patches fixed by build issues for 4.2.2.

[glennpj]

How is java_tools patched? It is not part of the bazel distribution that I downloaded. Do I need to grab one of the releases from https://github.com/bazelbuild/java_tools/releases and place it in the bazel source directory?

[davido]

This issue seems to be outdated.