Hi Rich,

Recently I briefly mentioned on IRC I've been working on a musl-cross-make
build for llvm/clang. I've reused the source download & patch infrastructure in
musl-cross-make and have added a new litecross implementation for clang.

The clang build tries to follow the same philosophy as the gcc build with one
key difference - it builds multiple targets into one toolchain.

Currently either gcc or clang is built by setting the COMPILER variable
(default gcc). It should be possible to do both at once but that would be a
bigger change.

I've had to fix a few things along the way to get this to hang together and
have included patches for the issues I came across. If you're happy with the
approach I'll submit these upstream.

The configure tests for the llvm runtime libraries are fairly awful and seem to
assume that a complete toolchain is available. There's two workarounds:
1. The RUNTIMES_*_CMAKE_{C,CXX}_FLAGS variables contain a -Qunused-arguments
   flag otherwise the cmake C/CXX compiler ABI detection tests fail. I couldn't
   work out another way of specifying the library/binary paths that worked.
2. The sysroot needs to contain crtbegin{T,S,}.o and crtend{S,}.o files for
   a few configure tests. I currently put empty dummies in there.

There doesn't appear to be a way to specify a name prefix for the clang/llvm
binaries. The build currently installs clang into a clang directory and
populates a bin directory with prefixed symlinks. This is to avoid clashing
with system binaries if the toolchain is added to $PATH.

I included a clang patch to support automatically selecting a sysroot based on
the --target argument. I thought it would be possible to do this using clang
configuration files but the --sysroot command line argument can't specify a
sysroot path which is relative to the clang binary. Only the build time
DEFAULT_SYSROOT has that capability.

There's a parallel build dependency problem somewhere in the install-runtimes
target of the llvm build system. It almost always fails to copy some files so
I've forced it to run single threaded for now.

I haven't used the resultant toolchain much yet. It builds working C and C++
"hello world" tests both statically and dynamically. I tried a toybox build and
that worked too.

I've attached a patch which should apply the current tip of the musl-cross-make
tree.

Patrick