Build failure for x86_64-unknown-linux-musl on Ubuntu 18.04.2-LTS

[jwarner112]

Hey there! First, thanks for this project. It will be quite a helpful building block for me on a few projects of mine.

For now however, I'm unable tomusl build for Linux x64.

Environment

I'm building using Purism's Librem15 (product page, product review), which sports an Intel i7-6500U @ 2.5Ghz x4 and 7.7GiB of RAM.

Problem

I've invoked the build from the HEAD of master using:

~/code/python-build-standalone $ python3 -V
Python 3.6.9
~/code/python-build-standalone $ pip -V
pip 20.1 from /home/user/.pyenv/versions/3.7.5/envs/build_standalone/lib/python3.7/site-packages/pip (python 3.7)
~/code/python-build-standalone $ python3 build-linux.py --python=cpython-3.8 --optimizations=pgo+lto --target=x86_64-unknown-linux-musl

I was able to see the build pull/build docker images and build most of the tools in the toolchain. But when it was working on clang, it choked with an error while trying to compile SemaDeclAttr.cpp.o:

clang> [3021/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaConcept.cpp.o
clang> [3022/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaCUDA.cpp.o
clang> [3023/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaCodeComplete.cpp.o
clang> [3024/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaChecking.cpp.o
clang> [3025/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclAttr.cpp.o
clang> FAILED: tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclAttr.cpp.o
clang> /tools/host/bin/g++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Sema -I/build/llvm/tools/clang/lib/Sema -I/build/llvm/tools/clang/include -Itools/clang/include -Iinclude -I/build/llvm/include -Wno-cast-function-type -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O3 -DNDEBUG    -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclAttr.cpp.o -MF tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclAttr.cpp.o.d -o tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclAttr.cpp.o -c /build/llvm/tools/clang/lib/Sema/SemaDeclAttr.cpp
clang> g++: fatal error: Killed signal terminated program cc1plus
clang> compilation terminated.
clang> [3026/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaExceptionSpec.cpp.o
clang> [3027/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclObjC.cpp.o
clang> [3028/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDecl.cpp.o
clang> [3029/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaDeclCXX.cpp.o
clang> [3030/4071] Building CXX object tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/SemaExpr.cpp.o
clang> ninja: build stopped: subcommand failed.

Workarounds I've tried

This StackOverflow thread suggested that the problem was memory limitations. As such, I tried:

1. Compiling without the --optimizations flag, which produced the same failure.
2. Modifying pythonbuild/buildenv.py to add mem_limit="4g" (as documented here) to the container instantiation, which led to the same failure yet again.

Here are the logs produced by the latest build -- with the mem_limit="4g" modification, but many of the images have not changed since their first successful runs (and the logs for them may not have been updated, either? I'm not certain)

• build.binutils-linux64.log

• build.clang-linux64.log

• build.gcc-linux64.log, split into five smaller files, ~25K lines each

  1. build.gcc-linux64.1.log
  2. build.gcc-linux64.2.log
  3. build.gcc-linux64.3.log
  4. build.gcc-linux64.4.log
  5. build.gcc-linux64.5.log

• build.image-image-build.log

• build.image-image-clang.log

• build.image-image-gcc.log

[indygreg]

I suspect you ran out of memory and the compilation process was being killed as a result. I would suggest adding a flag to the ninja command used to build Clang to explicitly limit how many parallel compilations can be performed. The rule of thumb is ~1 GB / parallel compile job. At 4 GB of memory plus overhead, you may only be able to compile with 2 or 3 processes in parallel without running out of memory.

[jwarner112]

I tried doing this and after (many) hours it hit a different error which I've since lost record of. That was on my laptop, so instead of trying that again I put an Ubuntu (Server) 20.04 VM on a Windows host (gave it 16gb RAM and 12 cores) and it failed to compile cpython-3.8 and cpython-3.7. I'm not sure whether or not these should qualify as their own issues or not. Here are some gists with the complete logs from invocation to failure.

• (first attempt) compiling cpython-3.8
• (second attempt) compiling cpython-3.7

Thoughts? I'll create new issues for these if necessary.

[indygreg]

Yeah, it is worth a new issue. The underlying failure appears to be InstrProfilingFile.c:(.text.parseAndSetFilename+0xfe): undefined reference to__strdup'`. I'm guessing musl just doesn't support LTO and/or PGO. (Or Python's configure script isn't handling something properly.) musl libc doesn't appear to be well supported by Python. So this warrants a closer look.

[jwarner112]

Created #46 and since I finally got a target compiled, I'll close this one.