[llvm-dev] [RFC] Strategies for Bootstrapping Compiler-RT builtins

[Vasileios Kalintiris via llvm-dev]

> The problem comes when bootstrapping a cross-compiler toolchain. In order to
> have a cross-compiling toolchain that can build a “hello world” application you
> need four basic components:
>
> (1) clang
> (2) ld
> (3) libclang_rt (builtins)
> (4) runtime libraries
>
> Today building this toolchain with CMake is impossible because you cannot
> configure the cross-compiled builtins. The failure is a result of CMake’s
> try_compile function always testing a full compile then link operation. When
> bootstrapping a cross-compiler this will always fail because linking even the
> simplest applications fails when you don’t have libclang_rt prebuilt.

In my case, I had to use the CMAKE_{C,CXX}_COMPILER_FORCED variables and
guestimate the appropriate C/C++ flags in order to avoid CMake getting in the
way with the various checks. My scripts build clang & lld, then install the
linux's kernel & Musl's C library headers and finally build compiler-rt's
builtins library (by setting COMPILER_RT_BUILD_SANITIZERS=Off). The next steps
build Musl, libunwind, libcxx and libcxxabi. This way I'm able to "use" CMake
for every LLVM project.

What isn't clear to me is whether you intend to extend your work to libunwind,
libcxx & libcxxabi because they do require a working C++ compiler too. Also,
my understanding is that the same is true for the sanitizers libraries. 

> So, how do we fix this? I have a couple ideas, and am open to more.
>
> ...
>
> (3) Split the builtins and the runtime libraries
>
> This is the most complicated approach, but I also think it is the best
> approach. One of the underlying problems here is that the builtin libraries
> and the runtime libraries have very different requirements for building. The
> builtins really only require a functional compiler and archiver, and the
> runtime libraries require a full linker + runtime libraries (libc & libcxx).
> These additional build-time requirements actually make things very
> complicated because when bootstrapping a cross toolchain compiler-rt needs to
> build in two different places in the build order; once before libcxx, and
> once after.

IMHO, from the options that you've mentioned, (3) is the cleanest one. 
Conceptually, as you mentioned the builtins library does not belong with the
sanitizers and it would make sense splitting them in separate repositories.
Would it be too difficult to create an initial split given that we already
provide/support the COMPILER_RT_BUILD_BUILTINS and COMPILER_RT_BUILD_SANITIZERS
options?

> Either way, supporting this approach will require significant cleanup and
> refactoring because we’ll need to separate out the build system functionality
> into three categories: things that apply to builtins, things that apply to
> runtimes, things that apply to both.

I don't have enought experience with CMake so I don't know how feasible this is,
but for the last two categories it would be nice to keep in mind that the user
might have a C library other than Glibc.

- Vasileios