bazel: Bazel cannot build itself in arm64 docker container

Description of the problem / feature request:

Bazel builds successfully but the compile.sh proceeds to build Bazel with Bazel and that fails. This is likely a bug in qemu, but I don’t know where to get enough detail out of Bazel to investigate it any further.

Feature requests: what underlying problem are you trying to solve with this feature?

ERROR: /root/bazel-0.21.0/src/BUILD:109:1: PythonZipper src/create_embedded_tools.zip failed (Exit 255): zipper failed: error executing command
  (cd /tmp/bazel_AM1PL7Q9/out/execroot/io_bazel && \
  exec env - \
    PATH=/bin:/usr/bin \
  bazel-out/host/bin/external/bazel_tools/third_party/ijar/zipper cC bazel-out/host/bin/src/create_embedded_tools.zip @bazel-out/host/bin/src/create_embedded_tools.zip-0.params)
Execution platform: @bazel_tools//platforms:host_platform
Target //src:bazel_nojdk failed to build
INFO: Elapsed time: 6149.498s, Critical Path: 1611.76s
INFO: 1641 processes: 1404 local, 237 worker.
FAILED: Build did NOT complete successfully

ERROR: Could not build Bazel

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

Dockerfile contents

FROM multiarch/ubuntu-core:arm64-bionic as base

RUN apt-get update -y
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
  python3 python3-dev python3-pip 

RUN pip3 install --upgrade pip

FROM base as bazel

RUN DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends \
  build-essential openjdk-8-jdk zip unzip wget python

WORKDIR /root

RUN wget https://github.com/bazelbuild/bazel/releases/download/0.21.0/bazel-0.21.0-dist.zip
RUN mkdir bazel-0.21.0
RUN unzip bazel-0.21.0-dist.zip -d bazel-0.21.0

WORKDIR /root/bazel-0.21.0

From a terminal running in the directory where Dockerfile is

$ docker run --rm --privileged multiarch/qemu-user-static:register --reset
$ docker build -t multiarch-bld .
$ docker run -it multiarch-bld
# ./compile.sh

What operating system are you running Bazel on?

$ uname -a
Darwin Seans-MacBook-Pro.local 18.2.0 Darwin Kernel Version 18.2.0: Mon Nov 12 20:24:46 PST 2018; root:xnu-4903.231.4~2/RELEASE_X86_64 x86_64
$ docker --version
Docker version 18.09.1, build 4c52b90

What’s the output of `bazel info release`?

None, it didn’t build.

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

When the above is run on an arm64 architecture (nVidia Jetson TX2 in my case), you can skip running the qemu-user-static container and it will build successfully.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 6
Comments: 27 (2 by maintainers)

Commits related to this issue

[Dist] Trying to fix aarch64/armv7l qemu-bazel problems Hint: https://github.com/bazelbuild/bazel/issues/7135 Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> — committed to nnsuite/tizenport-bazel by myungjoo 5 years ago
Update blaze_util_linux.cc https://github.com/bazelbuild/bazel/issues/7135#issuecomment-536775541 — committed to Unicamp-OpenPower/bazel by lcnzg 5 years ago
Add READ access of mmap() in docker env In docker multi-architecture environment, calling the mmap() with only PROT_WRITE would fail the following write(). Adding PROT_READ access would solve the iss... — committed to yhwang/bazel by yhwang 4 years ago

Most upvoted comments

Thanks for the comments here.

@ArielleA and me will try to get our ARM port effort rebooted soon and will see what we can do here!

philwo on May 6, 2019

Ugly fix, but you get the idea.

diff -rpu a/src/main/cpp/blaze_util_linux.cc b/src/main/cpp/blaze_util_linux.cc
--- a/src/main/cpp/blaze_util_linux.cc  1980-01-01 00:00:00.000000000 -0800
+++ b/src/main/cpp/blaze_util_linux.cc  2019-09-11 23:19:25.444000000 -0700
@@ -85,7 +85,8 @@ string GetSelfPath() {
   // The file to which this symlink points could change contents or go missing
   // concurrent with execution of the Bazel client, so we don't eagerly resolve
   // it.
-  return "/proc/self/exe";
+  static char path[PATH_MAX];
+  return realpath("/proc/self/exe", path);
 }
 
 uint64_t GetMillisecondsMonotonic() {

3XX0 on Sep 30, 2019

I have been playing with this as well. The zipper in question is not from python. It’s a built in third party tool. I have been able to build zipper manually by doing the following:

source scripts/bootstrap/buildenv.sh
BAZEL_JAVAC_OPTS="-J-Xms384m -J-Xmx768m" source scripts/bootstrap/compile.sh
source scripts/bootstrap/bootstrap.sh
bazel_build third_party/ijar:zipper

The compile.sh builds the bazel_build bootstrapped bazel that can build the release bazel. This bazel_build can be used to build zipper which is in third_party/ijar:zipper

It almost looks like the dependency is not there such that it doesn’t build zipper before it actually needs it. I don’t know what this has to do with qemu. After building zipper I was able to run it. I’m not so great with bazel syntax. Are we able to verify that it’s actually building zipper before it tries to use it?

snowzach on Aug 14, 2019

@ArielleA et al, Please don’t forget about arm32.

AleksandarFilipov on May 28, 2019