[compiler-rt] circular dependency on libc

[nickdesaulniers]

cc @petrhosek @frobtech @michaelrj-google @pcc @compnerd

Ideally, we'd be able to build the compiler builtins without depending on the libc (for purposes of bootstrapping a system). Right now, I observe build failures for the builtins ninja target when attempting to bootstrap such a sysroot:

• compiler-rt/lib/builtins/emutls.c depends on <stdlib.h>
• compiler-rt/lib/builtins/clear_cache.c depends on <assert.h>
• compiler-rt/lib/builtins/enable_execute_stack.c depends on <sys/mman.h>
• compiler-rt/lib/builtins/eprintf.c depends on <stdio.h>
• compiler-rt/lib/builtins/cpu_model/x86.c depends on <assert.h>

It looks like COMPILER_RT_BAREMETAL_BUILD can be unset to disable the addition of emutls.c, enable_execute_stack.c, and eprintf.c . (Ah @petrhosek has been here before, thanks @petrhosek !) AFAICT, there's currently no cmake option to skip building the rest.

Otherwise, it seems like we may have a circular dependency between the compiler builtins and the libc.

[frobtech]

This is often unavoidable in the general case, and isn't inherently a problem. The traditional way to address this is to separate making libc's headers available to compile against from building libc's code. For example, glibc's build system offers an install-headers target that can be used before building GCC and libgcc.

I think what we need here is some cmake way to indicate that building builtins depends on building/installing libc headers, and then building libc proper depends on builtins.

[nickdesaulniers]

Looks like llvm-libc has the ninja target install-libc-headers; let me give that a shot.

[petrhosek]

This is often unavoidable in the general case, and isn't inherently a problem. The traditional way to address this is to separate making libc's headers available to compile against from building libc's code. For example, glibc's build system offers an install-headers target that can be used before building GCC and libgcc.

I think what we need here is some cmake way to indicate that building builtins depends on building/installing libc headers, and then building libc proper depends on builtins.

We already do this for libc++ headers in a handful of places in compiler-rt, for example:

llvm-project/compiler-rt/lib/xray/CMakeLists.txt

Line 219 in 635e154

set(XRAY_DEPS cxx-headers)

llvm-project/compiler-rt/lib/orc/CMakeLists.txt

Line 48 in 635e154

set(ORC_DEPS cxx-headers)

To allow libc to depend on builtins, we need to integrate the builtins build into the runtimes build which is a more daunting task, but something I'd like to explore because it'd significantly simply the bootstrapping build.

[petrhosek]

Looks like llvm-libc has the ninja target install-libc-headers; let me give that a shot.

I don't think we should be using the install-libc-headers target, that copies the headers into the installation directory but during build we should be only only using the content of the build directory. Instead, we should use the libc-headers target:

llvm-project/libc/include/CMakeLists.txt

Line 728 in 635e154

add_library(libc-headers INTERFACE)

[quic-k]

hi @nickdesaulniers
can you or someone else take a look at this, should be related #165384