libc: make all builds LLVM_ENABLE_RUNTIMES

[nickdesaulniers]

No longer will any CI builds use LLVM_ENABLE_PROJECTS, which is deprecated as
of llvm/llvm-project#117265.

Buildbots will probably need their CMakeCache.txt reset after this.

Link: llvm/llvm-project#78479

[nickdesaulniers]

@gkistanova the presubmit check failure looks related to 618344c. Can you PTAL?

EDIT: posted a revert: #326

[nickdesaulniers]

@asb looks like I'm still hitting that presubmit error even though #323 has been merged (11 hours ago). Perhaps we should just revert fab27e2 + 618344c?

[nickdesaulniers]

I suspect the ASAN builds will be messed up by this change. Trying to confirm locally. Marking this as draft as such.

[nickdesaulniers]

I suspect the ASAN builds will be messed up by this change. Trying to confirm locally. Marking this as draft as such.

Ah, the issue is that locally, I'm setting -DCMAKE_CXX_COMPILER= and -DCMAKE_C_COMPILER= to local builds of clang that are in my $PATH but I have not installed them into /usr/bin; same for the compiler-rt includes. This isn't an issue on the buildbots as they have the compiler-rt headers installed.

Personally, I think we may want to change how that works, such that

$ cmake ../runtimes -GNinja -DLLVM_ENABLE_LLD=ON -DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_RUNTIMES="libc;compiler-rt" -DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ -DLLVM_USE_SANITIZER=Address

just works by building compiler-rt, then setting -I {build_dir}/compiler-rt/include/ for the build of llvm-libc. I may be wrong, but for the purposes of this PR, I don't think it will break the asan build bot (famous last words).

[nickdesaulniers]

A quick:

$ sudo mkdir /usr/local/include/sanitizer /usr/local/include/fuzzer /usr/local/include/xray /usr/local/include/orc /usr/local/include/profile
$ sudo chown -R `whoami` /usr/local/include/sanitizer /usr/local/include/fuzzer /usr/local/include/xray /usr/local/include/orc /usr/local/include/profile
$ ninja install-compiler-rt-headers

later and I can build via:

$ cmake ../runtimes -GNinja -DLLVM_ENABLE_LLD=ON -DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_RUNTIMES="libc;compiler-rt" -DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ -DLLVM_USE_SANITIZER=Address

$ <the above>

$ ninja libc

perhaps I should document this...

[asb]

@asb looks like I'm still hitting that presubmit error even though #323 has been merged (11 hours ago). Perhaps we should just revert fab27e2 + 618344c?

Seems to be OK now - I guess you addressed this with a rebase? I imagine previous failures were because the pre-commit checks were running against a base repo that didn't include #323.

[nickdesaulniers]

/me shrug

ok then I think this is ready for review.

[michaelrj-google]

I think you still need llvm in projects because the cmake command is rooted in the llvm directory. See run_command(['cmake', os.path.join(source_dir, 'llvm')] + cmake_args)

[nickdesaulniers]

Have you verified that? I've been doing runtimes builds (rooted in the runtimes dir) locally without ANY value set for -DLLVM_ENABLE_PROJECTS for building+testing libc for a while now. Even when I did core clang+llvm work, I think would use the llvm/ dir as the root and only explicitly list clang and lld in my -DLLVM_ENABLE_PROJECTS. So I would be surprised if llvm needed to appear explicitly in -DLLVM_ENABLE_PROJECTS when using llvm/ dir as the root for cmake (for llvm-libc, or any other sub project).

---

From a recent team discussion though, @lntue and @michaelrj-google mentioned that the use of llvm/ dir as the root and clang in the projects list will do a bootstrap build.

@lntue also pointed out this this is how we're testing fixed point support continuously, since the old clang most other buildbots are running are too old for fixed point support. Landing this PR right now would regress our CI coverage for fixed point.

So I think it's important to distinguish "bootstrap" builds (i.e. build clang first, then llvm-libc with that clang) from "runtimes" builds (anchored in runtimes/ for cmake). Those are two distinct things to me which are currently being conflated by the term "runtimes."

I have near term goals to move all build bots to newer versions of clang. That alone will resolve having coverage for fixed point.

It may still be handy to have "bootstrap" builds in CI, though they will take much longer to run since they need to build all of llvm and clang first.

Next steps to me then are perhaps:

1. rename debian-dbg-runtimes-build to debian-dbg-bootstrap-build (rather than spin down debian-dbg-runtimes-build as I had originally intended in [libc] consider using runtimes/CMakeLists.txt as base (rather than llvm/CMakeLists.txt) llvm-project#78479 (comment). This splits the conflation of runtimes with runtimes/ cmake root from "bootstrap" builds. Probably need to update buildbot config files, move/rename dirs, and wipe build dirs.
2. update this PR to move remaining builds to LLVM_ENABLE_RUNTIMES

[michaelrj-google]

SGTM

[nickdesaulniers]

#332 as precursor so that 1 doesn't turn off any CI builds.

[nickdesaulniers]

https://lab.llvm.org/buildbot/#/builders?tags=libc now shows that libc-x86_64-debian-dbg-runtimes-build has been renamed to libc-x86_64-debian-dbg-bootstrap-build. I've rebased this and updated it, so this thread should be resolved. Ready for rereview.

[nickdesaulniers]

PSA: I plan to land this after lunch (~2 hours from now), then be around to put out fires that may spring up this afternoon.

[lntue]

does it mean that we always build libc using clang from head?

[nickdesaulniers]

Only for the "bootstrap" builder (1 out of 13 active builders).

[nickdesaulniers]

Traceback (most recent call last):
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 158, in step
    yield
  File "../llvm-zorg/zorg/buildbot/builders/annotated/libc-linux.py", line 90, in main
    cmake_args.append('-DLLVM_ENABLE_PROJECTS={}'.format(';'.join(projects)))
UnboundLocalError: local variable 'projects' referenced before assignment

[nickdesaulniers]

#341

[nickdesaulniers]

Running: cmake ../llvm-project/llvm -GNinja -DLLVM_ENABLE_RUNTIMES=libc -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug -DLLVM_USE_SANITIZER=Address -DLLVM_LIBC_FULL_BUILD=ON
CMake Warning at CMakeLists.txt:154 (message):
  Using LLVM_ENABLE_PROJECTS=libc is deprecated now, and will become a fatal
  error in the LLVM 21 release.  Please use -DLLVM_ENABLE_RUNTIMES=libc or
  see the instructions at https://libc.llvm.org/ for building the runtimes.

homie...libc isn't even in LLVM_ENABLE_PROJECTS...time to go flush the buildbot's cmakecache...

[nickdesaulniers]

Fullbuilds are now failing with:

CMake Error at /home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-project/compiler-rt/cmake/Modules/AddCompilerRT.cmake:71 (add_dependencies):
  The dependency target "libc-headers" of target
  "RTScudoStandaloneCWrappers.aarch64" does not exist.

They were configured via:

Running: cmake ../llvm-project/llvm -GNinja -DLLVM_ENABLE_RUNTIMES=libc -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug "-DLLVM_ENABLE_PROJECTS=clang;compiler-rt" -DLLVM_LIBC_INCLUDE_SCUDO=ON -DCOMPILER_RT_BUILD_SCUDO_STANDALONE_WITH_LLVM_LIBC=ON -DCOMPILER_RT_BUILD_GWP_ASAN=OFF -DCOMPILER_RT_SCUDO_STANDALONE_BUILD_SHARED=OFF -DLIBC_INCLUDE_BENCHMARKS=ON -DLLVM_LIBC_FULL_BUILD=ON

[nickdesaulniers]

ah, I totally missed setting the cmake root as the runtimes dir...