cannot build Bazel 3.7.0 from source: ./src/main/tools/logging.h:44:27: error: expected ')' before 'PRId64'

[ghost]

Description of the problem / feature request:

I'm unable to build Bazel 3.7.0 from source on CentOS 8 using GCC 6.4.0 w/ a glibc-2.12 sysroot.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I'm using Bazel 3.3.0 from a dist zip (a bootstrapped Bazel build) to build 3.7.0 from Git.

$ bazel --bazelrc=/dev/null build //src:bazel_nojdk --compilation_mode=opt

What operating system are you running Bazel on?

CentOS 8 w/ GCC 6.4.0 and glibc-2.12.

What's the output of bazel info release?

$ bazel info release
release 3.3.0+vmware_bootstrap

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

n/a

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

n/a

Have you found anything relevant by searching the web?

See https://stackoverflow.com/a/8132440 .

Any other information, logs, or outputs that you want to share?

Commit f5eee73 appears to be the culprit. I'm able to fix this by applying the following:

commit 968530fcc65c475de61d20764454b87fa877b79b (origin/topic/beasleyr/vmware-3.7.0)
Author: Ryan Beasley <beasleyr@vmware.com>
Date:   Tue Oct 20 11:40:09 2020 -0700

    linux-sandbox: don't assume -lrt, -D__STDC_FORMAT_MACROS

diff --git a/src/main/tools/BUILD b/src/main/tools/BUILD
index 91b26df799..22c2912ed3 100644
--- a/src/main/tools/BUILD
+++ b/src/main/tools/BUILD
@@ -41,7 +41,8 @@ cc_binary(
     }),
     linkopts = select({
         "//src/conditions:windows": [],
-        "//conditions:default": ["-lm"],
+        "//src/conditions:darwin": ["-lm"],
+        "//conditions:default": ["-lm", "-lrt"],
     }),
     deps = select({
         "//src/conditions:windows": [],
@@ -89,7 +90,16 @@ cc_binary(
             "linux-sandbox-pid1.h",
         ],
     }),
-    linkopts = ["-lm"],
+    linkopts = select({
+        "//src/conditions:darwin": [],
+        "//src/conditions:darwin_x86_64": [],
+        "//src/conditions:darwin_arm64": [],
+        "//src/conditions:darwin_arm64e": [],
+        "//src/conditions:freebsd": [],
+        "//src/conditions:openbsd": [],
+        "//src/conditions:windows": [],
+        "//conditions:default": ["-lm", "-lrt"],
+    }),
     deps = select({
         "//src/conditions:darwin": [],
         "//src/conditions:darwin_x86_64": [],
diff --git a/src/main/tools/logging.h b/src/main/tools/logging.h
index c3abe35e23..14b46c9256 100644
--- a/src/main/tools/logging.h
+++ b/src/main/tools/logging.h
@@ -15,6 +15,10 @@
 #ifndef SRC_MAIN_TOOLS_LOGGING_H_
 #define SRC_MAIN_TOOLS_LOGGING_H_

+// See https://stackoverflow.com/a/8132440 .
+#ifndef __STDC_FORMAT_MACROS
+#define __STDC_FORMAT_MACROS
+#endif
 #include <inttypes.h>
 #include <stdint.h>
 #include <stdio.h>

[ghost]

FYI, the -lrt is required due to the following:

bazel-out/k8-opt/bin/src/main/tools/_objs/linux-sandbox/linux-sandbox.o: In function `main':                         
linux-sandbox.cc:(.text.startup.main+0x1bd): undefined reference to `clock_gettime'                                  
linux-sandbox.cc:(.text.startup.main+0x243): undefined reference to `clock_gettime'                                  
linux-sandbox.cc:(.text.startup.main+0x2ae): undefined reference to `clock_gettime'                                  
linux-sandbox.cc:(.text.startup.main+0x420): undefined reference to `clock_gettime'                                  
linux-sandbox.cc:(.text.startup.main+0x467): undefined reference to `clock_gettime'                                  
bazel-out/k8-opt/bin/src/main/tools/_objs/linux-sandbox/linux-sandbox.o:linux-sandbox.cc:(.text.startup.main+0x4c9): more undefined references to `clock_gettime' follow                                                                   
collect2: error: ld returned 1 exit status 

[benjaminp]

Wouldn't it be simpler to add -lrt to all Unixy linkflags? POSIX requires such a library exist.

[ghost]

Wouldn't it be simpler to add -lrt to all Unixy linkflags? POSIX requires such a library exist.

In which chunk? In the first chunk (:process-wrapper), librt doesn't exist on macOS (not in the base system or Xcode distribution). As for the second (:linux-sandbox), I'm using the same set of conditions as in srcs and deps, because only on Linux do we actually compile linux-sandbox.cc. (All other platforms compile dummy-sandbox.c.) In this case, the macOS situation still applies, but it also appears that OpenBSD doesn't provide librt, so I'd end up breaking the build on that platform if even only Linux and OpenBSD were grouped together. (I assume these other platforms just provide the necessary impls as part of their main libc libraries.)

Please lmk if I'm missing something obvious. :)

[benjaminp]

I was mainly referring to the FreeBSD case, but I neglected to note its linux-sandbox.

[pilkjaer]

I have encountered similar issue on RHEL7 machine. I solved it by adding following flags to the bazel when building bazel:
--copt=-D__STDC_FORMAT_MACROS
--host_copt=-D__STDC_FORMAT_MACROS
I don't know if it's a proper way but at least it solved the problem for me. Also changing compiler to newer version of gcc helped as well.

[katre]

Does this still happen when bootstrapping without a previous Bazel? What about when bootstrapping 3.7.0 with 3.6.0?

[katre]

I am able to bootstrap from source on Centos 8:

Start centos8:
$ docker run -it --rm --network=host centos:centos8

Download Bazel and prep system
$ curl -L https://github.com/bazelbuild/bazel/releases/download/3.7.0/bazel-3.7.0-dist.zip --output bazel-3.7.0-dist.zip
$ dnf install java-1.8.0-openjdk-devel python3 which zip unzip
$ dnf groupinstall "Development Tools"
$ alternatives --install /usr/bin/unversioned-python python /usr/bin/python3.6

# Bootstrap
$ unzip bazel-3.7.0-dist.zip
$ ./compile.sh
...
Build successful! Binary is here: /root/bootstrap/output/bazel

So I do not think this qualifies as a release blocker.

[ghost]

Does this still happen when bootstrapping without a previous Bazel? What about when bootstrapping 3.7.0 with 3.6.0?

Yes, this still occurs when bootstrapping 3.7.0 (unpacking the dist zip) using GCC 6.4.0 and glibc-2.12. (More on this below.) I'm not sure about when building with 3.6.0, but I assume it will as well.

I am able to bootstrap from source on Centos 8:

While I'm building on a CentOS 8 host, I'm using an out-of-tree compiler and glibc to target CentOS 6. (Our builds are detached from the host OS, so the compiler, libc, etc. are all versioned independently of the OS. We still need to support a body of engineers on CentOS 6 until they all finish migrating to CentOS 7/8.)

So I do not think this qualifies as a release blocker.

You're probably right.

Bazel's GCC and glibc requirements are a bit squishy (no minimum requirements are declared anywhere), but previously I've had changes merged which addressed compiler/libc breakages. It appears that headers in src/tools/singlejar include similar changes since 070859a and 612b1ed.

That all said, the Error Prone issue mentioned in #12188 OTOH likely is, and so if there was going to be a 3.7.1 I wondered if this issue could/should be swept up in the same release.

[grayed]

Wouldn't it be simpler to add -lrt to all Unixy linkflags? POSIX requires such a library exist.

No, librt is a POSIX extension.

[philwo]

@beasleyr-vmw Your proposed patch looks good to me, mind sending it in as a pull request?

[ghost]

@beasleyr-vmw Your proposed patch looks good to me, mind sending it in as a pull request?

Sure, done -- thanks! #12662