This patch adds in CMake option LLVM_ENABLE_LLVM_LIBC which when set to
true will detect if LLVM libc is available from the host linker, and if it is, all built
executables will be linked against the libc overlay.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This was mentioned at the 2022 US Dev Meeting and I've talked to some people who are interested in linking LLVM against LLVM libc, so I thought I would take a stab at it. Maybe we want to emit a warning that this isn't necessarily a supported configuration given that last I heard there were some test regressions when linking LLVM against LLVM libc?
I'm not against this approach, but keep in mind that we already discussed deprecating support for building runtimes with LLVM_ENABLE_PROJECTS at which point this approach is going to break. I'd be more interested in the alternative where we build a first stage Clang, then build libc as part of the runtimes build, and then build a second stage Clang and link against the libc built in the first stage. It's how we already build and link against other runtimes (builtins, libunwind, libc++abi, libc++) in our toolchain build.
Thanks for the feedback! That's definitely a good point. I was planning on integrating this with the three stage clang builds through the use of BOOTSTRAP_ CMake options to get the same effect as the runtime builds (building with a ToT clang), but integrating it directly into the existing runtimes build at this point makes a lot more sense.
Changed from building libc as a project and linking against that to linking against the LLVM libc overaly if available from the system. This prevents building something that should be built as a runtime as a project, ensuring that we have an up to date compiler.
In order to effectively do multi-stage builds https://reviews.llvm.org/D151624 needs to land.
I used llvm_check_linker_flags here to test if the library can be linked against. Using find_library seems like it would be best practice, but as far as my experimentation goes, the default search paths that find_library goes through doesn't include the <compiler binary dir>../lib/<target triple> directory that stores runtime build artifacts for multi-stage builds. I'm very open to changing that element if there's a better option.
We usually use check_library_exists for these types of checks, see https://cmake.org/cmake/help/latest/module/CheckLibraryExists.html. The name of the variable should be HAVE_LLVM_LIBC for consistency with the rest of LLVM.
llvm/cmake/modules/HandleLLVMOptions.cmake | ||
---|---|---|
1304 | Can you make it an option akin to LLVM_ENABLE_LIBCXX and also move this to llvm/CMakeLists.txt? See https://github.com/llvm/llvm-project/blob/e9ddb584e80194ab9f54e873aa733ae97da3bb95/llvm/CMakeLists.txt#L560 for reference. |
This should be HAVE_LLVM_LIBC.