32-bit Build on Debian 8 Jessie Fails, Output folder empty #1476
Comments
|
From the output it is clear that the initial java compilation somehow failed; so the whole bootstrap process got aborted with non-zero exit value. Your build did not even get to the "Building Bazel with Bazel" step. Everything happening till there is an invocation of the protoc compiler, javac for getting your bootstrap bazel, and a bunch of archive invocations. If you set the environemnt variable |
|
Can you please run |
|
Hi @aehlig , so I tried what you told me and I will try and truncate the output for brevity. It gives a I cloned the master branch again, to make sure the process was repeatable: I used the same repository, switching to another branch and it built without errors. Here is what I did to build the older one: The issue is that I require a newer branch than |
|
Hi,
It is not unplausible, that the amount of memory needed for the initial compilation of bazel Thanks, Klaus Aehlig |
|
No answer so closing, please ping if you still needs help. |
|
Sorry guys, i sold the 32-Bit system without being able to test it in further detail. I am assuming this should fix the problem as it was related to java and memory consumption. Thanks for your help. |
|
No problem. Thanks for the update! On Fri, Jul 29, 2016 at 11:52 AM natemccoy [email protected] wrote:
|
|
So tonight I tried to compile Bazel from the 0.4.4 distzip on 32 bit ubuntu 14.04. I encountered the same OOM, and @aehlig 's patch fixed[1] it. I was curious what the default heap sizes for javac were, so here they are on my 32bit and 64bit systems: 256MB on 32bit 4GB on 64bit [1] It fixed the OOM and presented another problem that I am too tired to attempt to debug right now: |
|
It seems related to the symlink 'cc1plus' not pointing to the g++ binary.
Try reinstalling g++ or fixing the symlink to point to the appropriate
binary for the CPP compiler.
…On 24 Feb 2017 7:25 a.m., "Adam Michael" ***@***.***> wrote:
So tonight I tried to compile Bazel from the 0.4.4 distzip on 32 bit
ubuntu 14.04. I encountered the same OOM, and @aehlig
<https://github.com/aehlig> 's patch fixed[1] it. I was curious what the
default heap sizes for javac were: so here they are on my 32bit and 64bit
systems:
256MB on 32bit
***@***.***:~$ javac -J-XX:+PrintFlagsFinal -version | grep MaxHeapSize
uintx MaxHeapSize := 268435456 {product}
javac 1.8.0_121
4GB on 64bit
***@***.***:~$ javac -J-XX:+PrintFlagsFinal -version | grep MaxHeapSize
uintx MaxHeapSize := 4278190080 {product}
javac 1.8.0_112
[1] It fixed the OOM and presented another problem that I am too tired to
attempt to debug right now:
***@***.***:~/bazel-0.4.4-dist$ ./compile.sh
INFO: You can skip this first step by providing a path to the bazel binary as second argument:
INFO: ./compile.sh compile /path/to/bazel
ð Building Bazel from scratch.......
ð Building Bazel with Bazel.
.WARNING: /tmp/bazel_8K2kNpvI/out/external/bazel_tools/WORKSPACE:1: Workspace name in /tmp/bazel_8K2kNpvI/out/external/bazel_tools/WORKSPACE ***@***.***_bazel) does not match the name given in the repository's definition ***@***.***_tools); this will cause a build error in future versions.
INFO: Found 1 target...
ERROR: /home/a/bazel-0.4.4-dist/src/main/cpp/util/BUILD:82:1: C++ compilation of rule '//src/main/cpp/util:logging' failed: gcc failed: error executing command
(cd /tmp/bazel_8K2kNpvI/out/execroot/bazel-0.4.4-dist && \
exec env - \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games \
/usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/bin -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections '-std=c++0x' -MD -MF bazel-out/local-opt/bin/src/main/cpp/util/_objs/logging/src/main/cpp/util/logging.d '-frandom-seed=bazel-out/local-opt/bin/src/main/cpp/util/_objs/logging/src/main/cpp/util/logging.o' -iquote . -iquote bazel-out/local-opt/genfiles -iquote external/bazel_tools -iquote bazel-out/local-opt/genfiles/external/bazel_tools -isystem external/bazel_tools/tools/cpp/gcc3 -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c src/main/cpp/util/logging.cc -o bazel-out/local-opt/bin/src/main/cpp/util/_objs/logging/src/main/cpp/util/logging.o): com.google.devtools.build.lib.shell.BadExitStatusException: Process exited with status 1.
gcc: error trying to exec 'cc1plus': execvp: No such file or directory
Target //src:bazel failed to build
INFO: Elapsed time: 5.954s, Critical Path: 0.43s
ERROR: Could not build Bazel
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1476 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABmkJq4_5ZKf-NEMsUW6ImKlwbfSR4cEks5rfoXTgaJpZM4JFHPy>
.
|
|
Thanks @natemccoy , the issue was just that I did not have g++ installed (we should probably have a better warning for that). Otherwise, the 32bit Bazel binary seems to be working fine. |
|
Thanks @aehlig, I followed the instruction but and I still get an error. Is there anyway to get around this? I am using Odroid 32bit arm7 |
I reviewed a few open issues such as #1340 and #850 which are related to 32-bit builds but cannot compile from source.
I followed the instructions on the installation page but nothing seems to be built, the return code from the compile script is non-zero which seems odd to me.
The
outputdirectory is empty and there were no errors output to stdout or stderr.I've tried the same procedure with the
--verbose_failuresflag inEXTRA_BAZEL_ARGSvariable in thecompile.shscript, but there was no change from the previous attempt.My java also seems to be the right version:
I looked in the
/tmpdirectory and see that a fewbazel.directories are created with.classfiles during the build process but I'm not sure what to look for if anything.Any suggestions?
Is there a way to determine where the failure is, and why nothing is in the
outputdirectory?The text was updated successfully, but these errors were encountered: