[all-commits] [llvm/llvm-project] 7ac1f6: [llvm-libgcc][CMake] Refactor llvm-libgcc (#65455)

ur4t via All-commits all-commits at lists.llvm.org
Mon Sep 18 22:56:17 PDT 2023

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7ac1f60f01a73f9678bba2385e933864ecce8622
  Author: ur4t <46435411+ur4t at users.noreply.github.com>
  Date:   2023-09-18 (Mon, 18 Sep 2023)

  Changed paths:
    M llvm-libgcc/CMakeLists.txt
    A llvm-libgcc/gcc_s.ver.in
    R llvm-libgcc/lib/CMakeLists.txt
    R llvm-libgcc/lib/blank.c
    R llvm-libgcc/lib/gcc_s.ver
    M runtimes/CMakeLists.txt

  Log Message:
  [llvm-libgcc][CMake] Refactor llvm-libgcc (#65455)

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

Commit c5a20b518203613497fa864867fc232648006068 ([llvm-libgcc] initial
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
with `libunwind`.

This patch fixes those issues by:

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

Adding target `llvm-libgcc`, creating symlinks, and utilizing cmake's
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
projects, considering that `llvm-libgcc` is only intended for toolchain
and not for casual use.

More information about the All-commits mailing list