mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-24 07:56:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm-libgcc/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

160 lines
6.6 KiB
CMake
Raw Permalink Normal View History

[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
#===============================================================================
# Setup Project
#===============================================================================
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
cmake_minimum_required(VERSION 3.20.0)
Revise IDE folder structure (#89755) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-05-25 17:41:21 +02:00
set(LLVM_SUBPROJECT_TITLE "LLVM libgcc")
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
set(LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
# Check if llvm-libgcc is built as a standalone project
if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LLVM_LIBGCC_STANDALONE_BUILD)
project(llvm-libgcc LANGUAGES C CXX ASM)
set(COMPILER_RT_STANDALONE_BUILD ON)
set_property(GLOBAL PROPERTY USE_FOLDERS ON)
set(LLVM_LIBGCC_COMPILER_RT_BINARY_DIR "compiler-rt")
set(LLVM_LIBGCC_LIBUNWIND_BINARY_DIR "libunwind")
else()
set(LLVM_LIBGCC_COMPILER_RT_BINARY_DIR "../compiler-rt")
set(LLVM_LIBGCC_LIBUNWIND_BINARY_DIR "../libunwind")
endif()
# Add path for custom modules
list(INSERT CMAKE_MODULE_PATH 0
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
"${CMAKE_CURRENT_SOURCE_DIR}/../runtimes/cmake/Modules"
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
)
set(LLVM_LIBGCC_LIBUNWIND_PATH "${CMAKE_CURRENT_LIST_DIR}/../libunwind"
CACHE PATH "Specify path to libunwind source.")
set(LLVM_LIBGCC_COMPILER_RT_PATH "${CMAKE_CURRENT_LIST_DIR}/../compiler-rt"
CACHE PATH "Specify path to compiler-rt source.")
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
include(GNUInstallDirs)
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
if(NOT LLVM_LIBGCC_EXPLICIT_OPT_IN)
message(FATAL_ERROR
"llvm-libgcc is not for the casual LLVM user. It is intended to be used by distro "
"managers who want to replace libgcc with compiler-rt and libunwind, but cannot "
"fully abandon the libgcc family (e.g. because they are dependent on glibc). Such "
"managers must have worked out their compatibility requirements ahead of using "
"llvm-libgcc. If you want to build llvm-libgcc, please add -DLLVM_LIBGCC_EXPLICIT_OPT_IN=Yes "
"to your CMake invocation and try again.")
endif()
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
if(HAVE_COMPILER_RT)
message(FATAL_ERROR
"Attempting to build both compiler-rt and llvm-libgcc will cause irreconcilable "
"target clashes. Please choose one or the other, but not both.")
endif()
if(HAVE_LIBUNWIND)
message(FATAL_ERROR
"Attempting to build both libunwind and llvm-libgcc will cause irreconcilable "
"target clashes. Please choose one or the other, but not both.")
endif()
#===============================================================================
# Configure System
#===============================================================================
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
[runtimes] Correctly apply libdir subdir for multilib (#93354) We weren't applying the libdir subdir to header directories but this is necessary for correctness when building e.g. ASan variant. This change also updates path construction logic accross all runtimes and ensures they're consistent.
2024-05-31 11:48:45 -07:00
set(TARGET_SUBDIR ${LLVM_DEFAULT_TARGET_TRIPLE})
if(LLVM_LIBGCC_LIBDIR_SUBDIR)
string(APPEND TARGET_SUBDIR /${LLVM_LIBGCC_LIBDIR_SUBDIR})
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
endif()
[runtimes] Correctly apply libdir subdir for multilib (#93354) We weren't applying the libdir subdir to header directories but this is necessary for correctness when building e.g. ASan variant. This change also updates path construction logic accross all runtimes and ensures they're consistent.
2024-05-31 11:48:45 -07:00
set(LLVM_LIBGCC_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${TARGET_SUBDIR})
set(LLVM_LIBGCC_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${TARGET_SUBDIR} CACHE PATH
"Path where built llvm-libgcc libraries should be installed.")
unset(TARGET_SUBDIR)
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
else()
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LLVM_LIBGCC_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
else()
set(LLVM_LIBGCC_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LLVM_LIBGCC_LIBDIR_SUFFIX})
endif()
set(LLVM_LIBGCC_INSTALL_LIBRARY_DIR lib${LLVM_LIBGCC_LIBDIR_SUFFIX} CACHE PATH
"Path where built llvm-libgcc libraries should be installed.")
endif()
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LLVM_LIBGCC_LIBRARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LLVM_LIBGCC_LIBRARY_DIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LLVM_LIBGCC_LIBRARY_DIR})
#===============================================================================
# Build libraries
#===============================================================================
set(COMPILER_RT_BUILD_BUILTINS ON)
set(COMPILER_RT_BUILTINS_HIDE_SYMBOLS OFF)
add_subdirectory(${LLVM_LIBGCC_COMPILER_RT_PATH} ${LLVM_LIBGCC_COMPILER_RT_BINARY_DIR})
set(LIBUNWIND_ENABLE_STATIC ON)
set(LIBUNWIND_ENABLE_SHARED ON)
set(LIBUNWIND_USE_COMPILER_RT OFF)
set(LIBUNWIND_HAS_GCC_LIB OFF)
set(LIBUNWIND_HAS_GCC_S_LIB OFF)
add_subdirectory(${LLVM_LIBGCC_LIBUNWIND_PATH} ${LLVM_LIBGCC_LIBUNWIND_BINARY_DIR})
add_custom_target(gcc_s.ver
SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/gcc_s.ver.in
COMMAND ${CMAKE_C_COMPILER} -E
-xc ${CMAKE_CURRENT_SOURCE_DIR}/gcc_s.ver.in
-o ${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver
)
add_dependencies(unwind_shared gcc_s.ver)
construct_compiler_rt_default_triple()
target_link_options(unwind_shared PUBLIC
-Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver
)
target_link_libraries(unwind_shared PUBLIC
$<TARGET_OBJECTS:clang_rt.builtins-${COMPILER_RT_DEFAULT_TARGET_ARCH}>
m
)
#===============================================================================
# Install Symlinks
#===============================================================================
get_compiler_rt_install_dir(${COMPILER_RT_DEFAULT_TARGET_ARCH} install_dir_builtins)
string(REGEX REPLACE "^lib/" "" install_dir_builtins "${install_dir_builtins}")
string(FIND "${install_dir_builtins}" "clang" install_path_contains_triple)
if(install_path_contains_triple EQUAL -1)
set(builtins_suffix "-${COMPILER_RT_DEFAULT_TARGET_ARCH}")
else()
string(PREPEND install_dir_builtins "../")
endif()
set(LLVM_LIBGCC_COMPILER_RT ${install_dir_builtins}/libclang_rt.builtins${builtins_suffix}.a)
add_custom_target(llvm-libgcc ALL
DEPENDS unwind_shared unwind_static clang_rt.builtins-${COMPILER_RT_DEFAULT_TARGET_ARCH}
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLVM_LIBGCC_COMPILER_RT} libgcc.a
COMMAND ${CMAKE_COMMAND} -E create_symlink libunwind.a libgcc_eh.a
COMMAND ${CMAKE_COMMAND} -E create_symlink libunwind.so libgcc_s.so.1.0
COMMAND ${CMAKE_COMMAND} -E create_symlink libgcc_s.so.1.0 libgcc_s.so.1
COMMAND ${CMAKE_COMMAND} -E create_symlink libgcc_s.so.1 libgcc_s.so
)
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
install(TARGETS unwind_shared unwind_static
LIBRARY DESTINATION ${LLVM_LIBGCC_INSTALL_LIBRARY_DIR} COMPONENT llvm-libgcc
ARCHIVE DESTINATION ${LLVM_LIBGCC_INSTALL_LIBRARY_DIR} COMPONENT llvm-libgcc
RUNTIME DESTINATION ${LLVM_LIBGCC_INSTALL_RUNTIME_DIR} COMPONENT llvm-libgcc)
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
install(TARGETS clang_rt.builtins-${COMPILER_RT_DEFAULT_TARGET_ARCH}
LIBRARY DESTINATION ${LLVM_LIBGCC_INSTALL_LIBRARY_DIR}/${install_dir_builtins} COMPONENT llvm-libgcc
ARCHIVE DESTINATION ${LLVM_LIBGCC_INSTALL_LIBRARY_DIR}/${install_dir_builtins} COMPONENT llvm-libgcc
RUNTIME DESTINATION ${LLVM_LIBGCC_INSTALL_RUNTIME_DIR}/${install_dir_builtins} COMPONENT llvm-libgcc)
[llvm-libgcc] initial commit Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`. Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the [Linux standard base][5]. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function `__GI___backtrace` eventually makes its way to a [hardcoded dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and libunwind have the same ABI, but different implementations, the two libraries end up [cross-talking, which ultimately results in a segfault][2]. To solve this problem, libunwind needs to build a “libgcc”. That is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`, and `libgcc_s.so`, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts. We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations. This problem has been solved in this manner for [FreeBSD][3], and this CL has been tested against [Chrome OS][4]. [1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16 [3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s [4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947 [5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html Differential Revision: https://reviews.llvm.org/D108416
2021-08-17 20:23:22 +00:00
[llvm-libgcc][CMake] Refactor llvm-libgcc (#65455) 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.
2023-09-19 13:56:03 +08:00
foreach(VAR libgcc.a libgcc_eh.a libgcc_s.so.1.0 libgcc_s.so.1 libgcc_s.so)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${VAR}
DESTINATION ${LLVM_LIBGCC_INSTALL_LIBRARY_DIR}
COMPONENT llvm-libgcc)
endforeach()
Reference in New Issue Copy Permalink