[llvm] [llvm-libgcc][CMake] Refactor llvm-libgcc (PR #65455)

via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 18 21:43:29 PDT 2023


ur4t wrote:

@cjdb Sorry for the circuitous commit history. I am glad to provide a summary.


[llvm-libgcc][CMake] Refactor llvm-libgcc

There are some issues in `llvm-libgcc` before this patch:

Commit c5a20b518203613497fa864867fc232648006068 ([llvm-libgcc] initial commit)
uses `$<TARGET_OBJECTS:unwind_static>` to get libunwind objects, which is empty.
The built library is actually a shared version of libclang_rt.builtins.

When configuring with `llvm/CMakeLists.txt`, target `llvm-libgcc` requires a
corresponding target in `llvm-libgcc/CMakeLists.txt`.

Per target installation is not handled by `llvm-libgcc`, which is not consistent
with `libunwind`.


This patch fixes those issues by:

Reusing target `unwind_shared` in `libunwind`, linking `compiler-rt.builtins`
objects into it, and applying version script.

Adding target `llvm-libgcc`, creating symlinks, and utilizing cmake's dependency
and component mechanism to ensure link targets will be built and installed along
with symlinks.

Mimicking `libunwind` to handle per target installation.


It is quite hard to set necessary options without further modifying the order of
runtime projects in `runtimes/CMakeLists.txt`. So though this patch reveals the
possibility of co-existence of `llvm-libgcc` and `compiler-rt`/`libunwind` in
`LLVM_ENABLE_RUNTIMES`, we still inhibit it to minimize influence on other
projects, considering that `llvm-libgcc` is only intended for toolchain vendors,
and not for casual use.


https://github.com/llvm/llvm-project/pull/65455


More information about the llvm-commits mailing list