Having less available should make debugging in the docker images a bit
more accessible.
Curl is a nice-to-have at the moment, while we also have wget available
from before.
LLVM's OpenMP implementation only supports Windows on x86, and it
requires a MASM-compatible assembler to build it. Build UASM
for this purpose, for now. (UASM isn't available packaged in
debian/ubuntu repos.) In the future, llvm-ml should be able
to handle it instead, but it's not currently mature enough.
Not including it in the regular build-all.sh for now, as UASM
isn't generally available.
This simplifies build-mingw-w64.sh. When building on native
windows (where we also provide unprefixed tools, we can't have
the yet incomplete compiler toolchain in $PATH when building
the mingw-w64 tools. (Logically, build-mingw-w64-tools belong
with build-llvm and install-wrappers; using the original system
compiler to build tools that are supposed to run on the current
machine, as opposed to the cross target, like when building the
runtimes.)
This updates compiler-rt, libunwind, libcxxabi and libcxx to a newer
version, matching the compiler.
This will be the official, canonical repo in the future.
For the non-dev Dockerfile build, this means that all the llvm based
subprojects need to be built in one RUN to avoid storing the llvm
checkout in the docker layers.
Now that we can build compiler-rt and libunwind with a stripped
llvm install, we can build things in a few smaller steps without
ending up with a larger docker image than before.
For x86 architectures, binutils objcopy and strip can be used as
such.
For armv7 and aarch64, binutils doesn't recognize the architectures
and refuse to touch the files. For most/everything that objcopy/strip
do, the actual architecture doesn't really matter though. Therefore,
provide a wrapper script and a minimal tool for editing PE executables,
that change the architecture from armv7 and aarch64 to i686 and x86_64
respectively before invoking binutils, and change it back afterwards.
In case the binutils tools are missing, just return a successful result
without doing anything for stripping operations (previously, we had the
<triplet>-strip tool symlinked to /bin/true, so this isn't any worse than
before) and fail for other objcopy operations.
gcc/libssp's configure script runs checks for flags that clang doesn't
implement. We actually just need to set a few HAVE defines and compile
the .c sources, so just check out this subdirectory using svn and build
it using a custom makefile.
This doesn't help reduce the docker image size since it's done
in a separate RUN step than the one that added the files. (compiler-rt
and libunwind currently fail to build after stripping the llvm
installation though.)
This makes the output architecture independent, allowing
the x86_64 GNU binutils binary to be used for other
architectures as well, including arm/arm64 which aren't supported
by binutils.
LLVM does have llvm-rc, which almost does what is needed.
Currently missing features:
- It doesn't run the C preprocessor (which can be wrapped with
a shellscript easily if necessary)
- It chokes on C structs/typedefs normally found in included
C headers
Provide wrappers named <triplet>-gcc and <triplet>-g++ as well,
to ease cross compilation with e.g. autotools, to allow just
specifying --host=<triplet>.
Provide wrappers for objdump and ld that provide specific output
that autotools look for.
Provide <triplet>-strip as a symlink to /bin/true, since there is
no strip tool available yet (and llvm-objcopy doesn't support
COFF yet).
Martin Storsjö