Not working on SLES 11.3

[kohlerm]

I tried to get bazel running on Suse SLES 11.3.
I did the following steps (roughly):
zypper addrepo http://download.opensuse.org/repositories/Archiving/SLE_11_SP3/Archiving.repo
zypper refresh
zypper install libarchive
zypper install libarchive-devel
zypper addrepo http://download.opensuse.org/repositories/Java:Factory/SLE_11_SP3/Java:Factory.repo
zypper refresh
zypper install java-1_8_0-openjdk
zypper install java-1_8_0-openjdk-devel
export JAVA_HOME=/usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/
./compile.sh
fails
~/bazel>./compile.sh
Compiling Java stubs for protocol buffers...
third_party/protobuf/protoc.amd64: /lib64/libc.so.6: version GLIBC_2.15' not found (required by third_party/protobuf/protoc.amd64) third_party/protobuf/protoc.amd64: /lib64/libc.so.6: versionGLIBC_2.14' not found (required by third_party/protobuf/protoc.amd64)

SLES 11.3 comes with glibc 2.11 ( I updated it)
~/bazel>zypper info glibc
Loading repository data...
Reading installed packages...

Information for package glibc:

Repository: sp3-updates
Name: glibc
Version: 2.11.3-17.82.11
Arch: x86_64
Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Support Level: Level 3
Installed: Yes
Status: up-to-date
Installed Size: 5.3 MiB
Summary: Standard Shared Libraries (from the GNU C Library)
Description:
The GNU C Library provides the most important standard libraries used
by nearly all programs: the standard C library, the standard math
library, and the POSIX thread library. A system is not functional
without these libraries.

I doubt glibc can be updated, so it would be good if bazel could work with this version of glibc.

[damienmg]

hanwen: I though the binary was completely static, I guess we don't bundle the GLIBC (make sense though). Can we lower the version of GLIBC needed? Or should we just mark that as another prerequesite to have bazel?

[kohlerm]

note that Suse 12.3 comes with glib 2.17 (v2.17-4.7.1 for me atm) so higher versions seem to work.

[hanwen]

The protoc binary we have now is 100% statically linked and should work on kernel 2.6.8 and later.

[philwo]

Just as a heads up, I've updated our protobuf library and compiler to the official binaries supplied by the protobuf team. The protoc binary is dynamically linked, but was built in a carefully crafted Docker container to make sure that it works with nearly all Linux versions out there.

I've tested it anyway, though, and as long as your Linux has glibc 2.5 or higher, we should be fine. This means: CentOS 5.x, Ubuntu 7.04, Debian 5 (Lenny) and SuSE Linux Enterprise 11 or higher are supported. If this breaks anyone, please reply to this issue and we'll find a solution.

[skearnes]

Hi, I'm working on a RHEL6 system (kernel 2.6.32-431.5.1.el6.x86_64) with glibc 2.12, but I get the following error when I run the 0.1.0 release:

$ ~/bin/bazel
bazel: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by bazel)

Upgrading glibc isn't really an option, but this thread suggests that I shouldn't have to. Any ideas?

[hanwen]

@skearnes - we can't support everything for the binary release. Have you tried compiling it from source?

[skearnes]

Yes; many times. The default gcc on the cluster is 4.4.7 and I get errors like:

$ ./compile.sh 
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh build /path/to/bazel
🍃  Building Bazel from scratch.....
Compiling client .cc files...
g++ -I. -std=c++0x -c -DBLAZE_JAVA_CPU="k8" -DBLAZE_OPENSOURCE=1 -o /tmp/bazel.fxv22fAN/objs/blaze_util.cc.o src/main/cpp/blaze_util.cc
src/main/cpp/blaze_util.cc: In function ‘bool blaze::IsStandardTerminal()’:
src/main/cpp/blaze_util.cc:219: error: ‘nullptr’ was not declared in this scope

When I load an updated compiler module (gcc 4.8.1), I get:

$ ./compile.sh 
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh build /path/to/bazel
🍃  Building Bazel from scratch............
🍃  Building Bazel with Bazel.
.WARNING: Output base '/cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb' is on NFS. This may lead to surprising failures and undetermined behavior.
Extracting Bazel installation...
Sending SIGTERM to previous Bazel server (pid=17048)... done.
..................
WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed. See http://bazel.io/docs/bazel-user-manual.html#sandboxing for more information. You can turn off this warning via --ignore_unsupported_sandboxing.
INFO: Found 1 target...
INFO: From Compiling src/main/tools/process-tools.c:
gcc: unrecognized option '-no-canonical-prefixes'
INFO: From Compiling src/main/tools/namespace-sandbox.c:
gcc: unrecognized option '-no-canonical-prefixes'
INFO: From Compiling third_party/ijar/zip.cc:
gcc: unrecognized option '-no-canonical-prefixes'
third_party/ijar/zip.cc: In function 'bool devtools_ijar::FindZipCentralDirectory(const devtools_ijar::u1*, size_t, devtools_ijar::u4*, const devtools_ijar::u1**)':
third_party/ijar/zip.cc:624: warning: comparison between signed and unsigned integer expressions
At global scope:
cc1plus: warning: unrecognized command line option "-Wno-free-nonheap-object"
INFO: From Compiling src/main/cpp/util/strings.cc:
gcc: unrecognized option '-no-canonical-prefixes'
src/main/cpp/util/strings.cc: In function 'void blaze_util::JoinStrings(const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&, char, std::string*)':
src/main/cpp/util/strings.cc:90: error: expected initializer before ':' token
src/main/cpp/util/strings.cc:305: error: expected primary-expression at end of input
src/main/cpp/util/strings.cc:305: error: expected ';' at end of input
src/main/cpp/util/strings.cc:305: error: expected primary-expression at end of input
src/main/cpp/util/strings.cc:305: error: expected ')' at end of input
src/main/cpp/util/strings.cc:305: error: expected statement at end of input
src/main/cpp/util/strings.cc:89: warning: unused variable 'first'
src/main/cpp/util/strings.cc:305: error: expected '}' at end of input
src/main/cpp/util/strings.cc: At global scope:
src/main/cpp/util/strings.cc:305: error: expected '}' at end of input
cc1plus: warning: unrecognized command line option "-Wno-free-nonheap-object"
ERROR: /cluster/home/kearnes/git/bazel/src/main/cpp/util/BUILD:31:1: C++ compilation of rule '//src/main/cpp/util:strings' failed: gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -DBLAZE_OPENSOURCE -iquote . ... (remaining 18 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
Target //src:bazel failed to build

With a gcc 4.9.3 module I get:

./compile.sh 
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO:    ./compile.sh build /path/to/bazel
🍃  Building Bazel from scratch............
🍃  Building Bazel with Bazel.
.WARNING: Output base '/cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb' is on NFS. This may lead to surprising failures and undetermined behavior.
Extracting Bazel installation...
Sending SIGTERM to previous Bazel server (pid=26877)... done.
..................
INFO: Waiting for response from Bazel server (pid 33683)...
WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed. See http://bazel.io/docs/bazel-user-manual.html#sandboxing for more information. You can turn off this warning via --ignore_unsupported_sandboxing.
INFO: Found 1 target...
INFO: From Creating runfiles tree bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main.runfiles:
/cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb/bazel/_bin/build-runfiles: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by /cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb/bazel/_bin/build-runfiles)
ERROR: /cluster/home/kearnes/git/bazel/src/main/java/BUILD:511:1: Creating runfiles tree bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main.runfiles failed: build-runfiles failed: error executing command /cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb/bazel/_bin/build-runfiles bazel-out/local_linux-fastbuild/bin/src/main/java/bazel-main.runfiles_manifest ... (remaining 1 argument(s) skipped): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
Target //src:bazel failed to build
Use --verbose_failures to see the command lines of failed build steps.

That last traceback seems to suggest that it's not actually using the updated compiler, but editing CROSSTOOL seems error-prone without some guidance.

[futurulus]

+1 for @skearnes 's issue...in particular we are also seeing the last output in his comment (CentOS 6.6, GCC 4.9.1, glibc 2.12).

[...] version `GLIBCXX_3.4.14' not found (required by /cluster/home/kearnes/.cache/bazel/_bazel_kearnes/d1d06965ef094ca408f3e849c820e5eb/bazel/_bin/build-runfiles)

This is blocking our installation of @tensorflow -- both the binaries for that library and the binaries for Bazel are linked against glibc 2.17, so we need to compile from source.

[saurabhkgp]

Facing the exact same issue as @skearnes . Not able to build bazel on RHEL6 with glibc2.12 - Here's the error I am getting -

INFO: You can skip this first step by providing a path to the bazel binary as second argument:
I Building Bazel from scratch.....o/bazel
Compiling client .cc files...
g++ -I. -std=c++0x -c -DBLAZE_JAVA_CPU="k8" -DBLAZE_OPENSOURCE=1 -o /tmp/bazel.E6OIY33y/objs/blaze_startup_options.cc.o src/main/cpp/blaze_startup_options.cc
as: error while loading shared libraries: libopcodes-2.20.51.0.2-5.20.el6_1.1.so: cannot open shared object file: No such file or directory

This is blocking our installation of @tensorflow -- both the binaries for that library and the binaries for Bazel are linked against glibc 2.17, so we need to compile from source.

[philwo]

@damienmg People are neither able to use our binary releases (due to incompatibility with the glibc we link them against), nor build Bazel from source. Do you have an idea what we could do here?

[kohlerm]

I wonder whether compiling bazel within a docker container would be helpful. That would probably also require to compile against glibc statically. Then get a statically compiled binary that runs everywhere (like docker itself)

[saurabhkgp]

@kohlerm , @damienmg - Docker might work but a vanilla RHEL6 install (both binary and source) not working for anyone is certainly frustrating. And given that bazel is a pre-requisite for building other Google offerings like Tensorflow (which doesn't have pre-built binaries for RHEL6/glibc2.12 either) makes it a real blocker.

[damienmg]

Normally compiling with CC, CXX and the likes flag should make the bootstrap work and editing tools/cpp/CROSSTOOL file should make bazel build works. If gcc is not in /usr/bin, those error will continue to happens.

We are working on better configurabilty of Bazel build but we are not yet here.

[mikecroucher]

As seen in the link above, we have a very similar problem with the HPC system at University of Sheffield.

[digitalsword]

I have a similar problem with Redhat 6.7

[sakett]

Facing the same issue on RHEL6 it is is blocking our tensorflow build

[damienmg]

The precise issue with build-runfiles should be gone at HEAD hopefully in the afternoon. So only tuning tools/cpp/CROSSTOOL should be enough to works for custom C++ compilers (if they support the c++0x standard).

[damienmg]

Both RHEL and RedHat should build fine from HEAD starting now