Cold-Air-Networks/mirror-llvm-project
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 7
mirror-llvm-project/libcxxabi/CMakeLists.txt

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

533 lines
23 KiB
Text
Raw Permalink Normal View History

[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
# See www/CMake.html for instructions on how to build libcxxabi with CMake.
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
#===============================================================================
# Setup Project
#===============================================================================
Reland "[CMake] Bumps minimum version to 3.20.0. This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6. Adds the patch by @hans from https://github.com/llvm/llvm-project/issues/62719 This patch fixes the Windows build. d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews D144509 [CMake] Bumps minimum version to 3.20.0. This partly undoes D137724. This change has been discussed on discourse https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193 Note this does not remove work-arounds for older CMake versions, that will be done in followup patches. D150532 [OpenMP] Compile assembly files as ASM, not C Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent) when compiling a file which has been set as having the language C. This behaviour change only takes place if "cmake_minimum_required" is set to 3.20 or newer, or if the policy CMP0119 is set to new. Attempting to compile assembly files with "-x c" fails, however this is workarounded in many cases, as OpenMP overrides this with "-x assembler-with-cpp", however this is only added for non-Windows targets. Thus, after increasing cmake_minimum_required to 3.20, this breaks compiling the GNU assembly for Windows targets; the GNU assembly is used for ARM and AArch64 Windows targets when building with Clang. This patch unbreaks that. D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump The build uses other mechanism to select the runtime. Fixes #62719 Reviewed By: #libc, Mordante Differential Revision: https://reviews.llvm.org/D151344
2023-05-24 08:12:32 -08:00
cmake_minimum_required(VERSION 3.20.0)
[CMake] Warn when the version of CMake is older than 3.31.0 (#204203) This is a preparation to raise the minimum required CMake version to 3.31.0 in LLVM 24. See https://discourse.llvm.org/t/rfc-raising-minimum-required-cmake-version-to-3-31/91086.
2026-06-29 10:16:27 -08:00
if("${CMAKE_VERSION}" VERSION_LESS "3.31.0")
message(WARNING
"Your CMake version is ${CMAKE_VERSION}. Starting with LLVM 24, the "
"minimum version of CMake required to build LLVM will become 3.31.0, and "
"using an older CMake will become an error. Please upgrade your CMake to "
"at least 3.31.0 now to avoid issues in the future.")
endif()
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 07:41:21 -08:00
set(LLVM_SUBPROJECT_TITLE "libc++abi")
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2021-12-31 22:03:31 -09:00
set(LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
[CMake][libcxxabi] Use -nodefaultlibs for CMake checks Since libc++abi is built with -nodefaultlibs, we should be using this option even for CMake checks to avoid any inconsistency and also to avoid dependency on a working C++ standard library just for the setting up the build itself. The implementation is largely similar to the one used by libc++. Differential Revision: https://reviews.llvm.org/D31639 llvm-svn: 299797
2017-04-07 12:10:41 -08:00
# Add path for custom modules
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2021-12-31 22:03:31 -09:00
list(INSERT CMAKE_MODULE_PATH 0
[CMake][libcxxabi] Use -nodefaultlibs for CMake checks Since libc++abi is built with -nodefaultlibs, we should be using this option even for CMake checks to avoid any inconsistency and also to avoid dependency on a working C++ standard library just for the setting up the build itself. The implementation is largely similar to the one used by libc++. Differential Revision: https://reviews.llvm.org/D31639 llvm-svn: 299797
2017-04-07 12:10:41 -08:00
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
[runtimes] Move common functions from Handle{Libcxx,Libcxxabi,Libunwind}Flags.cmake to runtimes/cmake/Modules/HandleFlags.cmake Reviewed By: phosek, #libunwind, #libc, #libc_abi Spies: arichardson, libcxx-commits Differential Revision: https://reviews.llvm.org/D144395
2023-02-20 06:26:19 -09:00
"${CMAKE_CURRENT_SOURCE_DIR}/../runtimes/cmake/Modules"
[CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity In D116472 we created conditionally defined variables for the tools to unbreak the legacy build where they are in `llvm/tools`. The runtimes are not tools, so that flexibility doesn't matter. Still, it might be nice to define (unconditionally) and use the variable for the runtimes simply to make the code a bit clearer and document what is going on. Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path. Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116477
2021-12-31 22:03:31 -09:00
"${LLVM_COMMON_CMAKE_UTILS}"
"${LLVM_COMMON_CMAKE_UTILS}/Modules"
[CMake][libcxxabi] Use -nodefaultlibs for CMake checks Since libc++abi is built with -nodefaultlibs, we should be using this option even for CMake checks to avoid any inconsistency and also to avoid dependency on a working C++ standard library just for the setting up the build itself. The implementation is largely similar to the one used by libc++. Differential Revision: https://reviews.llvm.org/D31639 llvm-svn: 299797
2017-04-07 12:10:41 -08:00
)
[libc++] Set CMAKE_FOLDER. NFC. * This variable populates the default value of FOLDER target property. It is used in some IDE's (e.g. MSVC) to group different targets together.
2021-01-24 23:50:03 -09:00
set(CMAKE_FOLDER "libc++")
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 01:01:05 -08:00
set(LIBCXXABI_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(LIBCXXABI_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
set(LIBCXXABI_LIBCXX_PATH "${CMAKE_CURRENT_LIST_DIR}/../libcxx" CACHE PATH
"Specify path to libc++ source.")
[cmake] Make include(GNUInstallDirs) always below project(..) Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this awkward, since the rest of the condition code may also need GNUInstallDirs. The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward. Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D117639
2022-01-18 21:45:07 -09:00
include(GNUInstallDirs)
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
# Require out of source build.
include(MacroEnsureOutOfSourceBuild)
MACRO_ENSURE_OUT_OF_SOURCE_BUILD(
"${PROJECT_NAME} requires an out of source build. Please create a separate
build directory and run 'cmake /path/to/${PROJECT_NAME} [options]' there."
)
[libc++abi] Provide an explicit error when trying to build for MSVC (#119370) Fixes #119322
2024-12-11 08:49:06 -09:00
if (MSVC)
message(FATAL_ERROR "Libc++abi can't be built for MSVC targets, and doing so is pointless anyway because such "
"targets must use the MS C++ ABI, and libc++abi provides the Itanium C++ ABI.")
endif()
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
#===============================================================================
# Setup CMake Options
#===============================================================================
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
include(CMakeDependentOption)
[CMake][libcxxabi] Use -nodefaultlibs for CMake checks Since libc++abi is built with -nodefaultlibs, we should be using this option even for CMake checks to avoid any inconsistency and also to avoid dependency on a working C++ standard library just for the setting up the build itself. The implementation is largely similar to the one used by libc++. Differential Revision: https://reviews.llvm.org/D31639 llvm-svn: 299797
2017-04-07 12:10:41 -08:00
include(HandleCompilerRT)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
# Define options.
[libcxxabi] Don't process exceptions in cxa_handlers when they're disabled When exceptions are disabled, avoid their processing altogether. This avoids pulling in the depenency on demangler significantly reducing binary size when statically linking against libc++abi built without exception support. Differential Revision: https://reviews.llvm.org/D64191 llvm-svn: 365944
2019-07-12 11:10:59 -08:00
option(LIBCXXABI_ENABLE_EXCEPTIONS
"Provide support for exceptions in the runtime.
When disabled, libc++abi does not support stack unwinding and other exceptions-related features." ON)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
option(LIBCXXABI_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
[runtimes] Synchronize warnings flags between libc++/libc++abi/libunwind This mostly keeps the same warning flags. The most important exceptions are `-Wpedantic` and `-Wconversion`, which are now removed from libc++abi and libunwind. Reviewed By: ldionne, #libunwind, #libc, #libc_abi Spies: mikhail.ramalho, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D144252
2023-02-17 01:31:41 -09:00
option(LIBCXXABI_ENABLE_PEDANTIC "Compile with pedantic enabled." OFF)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
[runtimes] Use LLVM libunwind from libc++abi by default (#77687) I recently came across LIBCXXABI_USE_LLVM_UNWINDER and was surprised to notice it was disabled by default. Since we build libunwind by default and ship it in the LLVM toolchain, it would seem to make sense that libc++ and libc++abi rely on libunwind for unwinding instead of using the system-provided unwinding library (if any). Most importantly, using the system unwinder implies that libc++abi is ABI compatible with that system unwinder, which is not necessarily the case. Hence, it makes a lot more sense to instead default to using the known-to-be-compatible LLVM unwinder, and let vendors manually select a different unwinder if desired. As a follow-up change, we should probably apply the same default to compiler-rt. Differential Revision: https://reviews.llvm.org/D150897 Fixes #77662 rdar://120801778
2024-01-11 06:13:21 -09:00
option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." ON)
[libc++abi] Improve error message when libunwind is missing from LLVM_ENABLE_RUNTIMES (#77991) This doesn't actually prevent the build from failing, but it provides a better diagnostic that explains what is needed in order to fix the build. Fixes #77846 Fixes #77843
2024-01-15 06:16:32 -09:00
if (LIBCXXABI_USE_LLVM_UNWINDER AND NOT "libunwind" IN_LIST LLVM_ENABLE_RUNTIMES)
[libc++abi] Fix typo in CMake error message
2024-01-16 06:55:56 -09:00
message(FATAL_ERROR "LIBCXXABI_USE_LLVM_UNWINDER is set to ON, but libunwind is not specified in LLVM_ENABLE_RUNTIMES.")
[libc++abi] Improve error message when libunwind is missing from LLVM_ENABLE_RUNTIMES (#77991) This doesn't actually prevent the build from failing, but it provides a better diagnostic that explains what is needed in order to fix the build. Fixes #77846 Fixes #77843
2024-01-15 06:16:32 -09:00
endif()
[libcxxabi][CMake] Support in-tree libunwind when building as part of runtimes When building as part of runtimes, there is no predefined order in which the runtimes are loaded, so the targets from other projects might not be available. We need to rely on HAVE_<name> variables instead in that case. Differential Revision: https://reviews.llvm.org/D29574 llvm-svn: 294552
2017-02-08 17:19:30 -09:00
option(LIBCXXABI_ENABLE_STATIC_UNWINDER "Statically link the LLVM unwinder." OFF)
libc++abi: add a top level option for using CompilerRT Add an option to opt into compiler-rt instead of libgcc. This option defaults to OFF to avoid a behaviour change. It is not possible to mix and match different runtime libraries. Disabling this requires that libc++ is built accordingly. This knob is particularly useful for targets that are GCC by default (i.e. Linux). llvm-svn: 275505
2016-07-14 16:49:42 -08:00
option(LIBCXXABI_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
[libcxxabi] Refactor building and testing libc++abi without threads Summary: This patch adds CMake support for building and testing libc++abi without threads. 1. Add `LIBCXXABI_ENABLE_THREADS` option to CMake. 2. Propagate `LIBCXXABI_ENABLE_THREADS` to lit via lit.site.cfg.in 3. Configure tests for `LIBCXXABI_ENABLE_THREADS=OFF Currently the test suite does not work when libc++abi is built without threads because that information does not propagate to the test suite. Reviewers: danalbert, mclow.lists, jroelofs Reviewed By: jroelofs Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6393 llvm-svn: 222702
2014-11-24 13:42:03 -09:00
option(LIBCXXABI_ENABLE_THREADS "Build with threads enabled" ON)
Allow explicit pthread opt-in When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi, along with llvm/projects/libcxx), libcxx's config_site.in doesn't get created in a timely manner. This means that any configuration that is normally set in libcxx's config_site.in needs to be duplicated in libcxxabi to successfully build libcxxabi. This patch does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. http://reviews.llvm.org/D20574 llvm-svn: 270732
2016-05-25 09:37:38 -08:00
option(LIBCXXABI_HAS_PTHREAD_API "Ignore auto-detection and force use of pthread API" OFF)
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection. This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++. Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++. Differential revision: https://reviews.llvm.org/D98021
2021-03-05 05:30:13 -09:00
option(LIBCXXABI_HAS_WIN32_THREAD_API "Ignore auto-detection and force use of win32 thread API" OFF)
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
option(LIBCXXABI_HAS_EXTERNAL_THREAD_API
"Build libc++abi with an externalized threading API.
This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON." OFF)
[libc++] Introduce the notion of a minimum header version (#166074) Introducing the notion of a minimum header version has multiple benefits. It allows us to merge a bunch of ABI macros into a single one. This makes configuring the library significantly easier, since, for a stable ABI, you only need to know which version you started distributing the library with, instead of checking which ABI flags have been introduced at what point. For platforms which have a moving window of the minimum version a program has been compiled against, this also makes it simple to remove symbols from the dylib when they can't be used by any program anymore.
2026-01-09 01:58:29 -09:00
set(LIBCXXABI_AVAILABILITY_MINIMUM_HEADER_VERSION "2" CACHE STRING
"Minimum version of the libc++ headers that are allowed to be used by binaries linked against the libc++ library. This
version must correspond to the major version of an LLVM release.")
[libc++/abi] Provide an option to turn on forgiving dynamic_cast when building libc++abi Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option to enable the setting when building libc++abi. Also use the occasion to rename the option to something slightly more descriptive. Note that in the future, it would be great to simply remove this option altogether. However, in the meantime, it seems better to have it be an official option than something ad-hoc.
2020-04-22 12:17:58 -08:00
option(LIBCXXABI_ENABLE_FORGIVING_DYNAMIC_CAST
"Make dynamic_cast more forgiving when type_info's mistakenly have hidden \
visibility, and thus multiple type_infos can exist for a single type. \
When the dynamic_cast would normally fail, this option will cause the \
library to try comparing the type_info names to see if they are equal \
instead." OFF)
Work around GCC linking errors within libc++abi due to missing new/delete definitions llvm-svn: 296823
2017-03-02 12:55:17 -09:00
[libc++abi] Add option to enable definitions for the new/delete overloads. Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them. This patch adds the CMake option `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS` which defaults to `OFF` unless otherwise specified. This means that by default only libc++ provides the new/delete definitions. Reviewers: mclow.lists, mehdi_amini, dexonsmith, beanz, jroelofs, danalbert, smeenai, rmaprath, mgorny Reviewed By: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30517 llvm-svn: 296801
2017-03-02 10:34:35 -09:00
option(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS
[libc++] Define new/delete in libc++abi only by default Previously, we would define new/delete in both libc++ and libc++abi. Not only does this cause code bloat, but also it's technically an ODR violation since we don't know which operator will be selected. Furthermore, since those are weak definitions, we should strive to have as few of them as possible (to improve load times). My preferred choice would have been to put the operators in libc++ only by default, however that would create a circular dependency between libc++ and libc++abi, which GNU linkers don't handle. Folks who want to ship new/delete in libc++ instead of libc++abi are free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at CMake configure time. On Apple platforms, this shouldn't be an ABI break because we re-export the new/delete symbols from libc++abi. This change actually makes libc++ behave closer to the system libc++ shipped on Apple platforms. On other platforms, this is an ABI break for people linking against libc++ but not libc++abi. However, vendors have been consulted in D68269 and no objection was raised. Furthermore, the definitions can be controlled to appear in libc++ instead with the CMake option. Differential Revision: https://reviews.llvm.org/D68269
2019-10-01 05:34:58 -08:00
"Build libc++abi with definitions for operator new/delete. These are normally
defined in libc++abi, but it is also possible to define them in libc++, in
which case the definition in libc++abi should be turned off." ON)
[runtimes] Remove support for GCC-style 32 bit multilib builds This patch removes the ability to build the runtimes in the 32 bit multilib configuration, i.e. using -m32. Instead of doing this, one should cross-compile the runtimes for the appropriate target triple, like we do for all other triples. As it stands, -m32 has several issues, which all seem to be related to the fact that it's not well supported by the operating systems that libc++ support. The simplest path towards fixing this is to remove support for the configuration, which is also the best course of action if there is little interest for keeping that configuration. If there is a desire to keep this configuration around, we'll need to do some work to figure out the underlying issues and fix them. Differential Revision: https://reviews.llvm.org/D114473
2021-11-23 12:34:09 -09:00
option(LIBCXXABI_BUILD_32_BITS "Build 32 bit multilib libc++abi. This option is not supported anymore when building the runtimes. Please specify a full triple instead." ${LLVM_BUILD_32_BITS})
if (LIBCXXABI_BUILD_32_BITS)
[runtimes] Move WARNING to FATAL_ERROR for folks using FOO_BUILD_32_BITS
2021-12-01 08:57:30 -09:00
message(FATAL_ERROR "LIBCXXABI_BUILD_32_BITS is not supported anymore when building the runtimes, please specify a full triple instead.")
[runtimes] Remove support for GCC-style 32 bit multilib builds This patch removes the ability to build the runtimes in the 32 bit multilib configuration, i.e. using -m32. Instead of doing this, one should cross-compile the runtimes for the appropriate target triple, like we do for all other triples. As it stands, -m32 has several issues, which all seem to be related to the fact that it's not well supported by the operating systems that libc++ support. The simplest path towards fixing this is to remove support for the configuration, which is also the best course of action if there is little interest for keeping that configuration. If there is a desire to keep this configuration around, we'll need to do some work to figure out the underlying issues and fix them. Differential Revision: https://reviews.llvm.org/D114473
2021-11-23 12:34:09 -09:00
endif()
[libcxxabi] Add flag to conditionally enable tests Differential Revision: https://reviews.llvm.org/D28449 llvm-svn: 291367
2017-01-07 13:14:04 -09:00
option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ${LLVM_INCLUDE_TESTS})
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 18:44:46 -08:00
set(LIBCXXABI_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
"Define suffix of library directory name (32/64)")
[libc++abi] Install the libc++abi headers from libc++abi libc++abi should be responsible for installing its own headers, it doesn't make sense for libc++ to be responsible for it. Differential Revision: https://reviews.llvm.org/D101458
2022-02-17 07:19:45 -09:00
option(LIBCXXABI_INSTALL_HEADERS "Install the libc++abi headers." ON)
[libcxxabi][CMake] Provide option to disable installing of the library This is useful in cases where we only build static library and libc++abi.a is combined with libc++.a into a single archive in which case we don't want to have libc++abi.a installed separately. The same option is already provided by libcxx CMake build. Differential Revision: https://reviews.llvm.org/D40194 llvm-svn: 318568
2017-11-17 14:25:09 -09:00
option(LIBCXXABI_INSTALL_LIBRARY "Install the libc++abi library." ON)
[libcxxabi] Copy headers into build location Prior to D120727, the libcxx build was responsible for copying libcxxabi headers into the right location, both in the build and install trees, but now it's the responsibility of the libcxxabi build. While the build already did the right thing for the install tree, it wouldn't copy headers into the build tree, resulting in errors when trying to use the just built toolchain as is the case in the runtimes build when building compiler-rt runtimes. Differential Revision: https://reviews.llvm.org/D125597
2022-05-13 18:23:52 -08:00
[runtimes] Don't create shared library targets when unsupported (#205517) On platforms that don't support shared libraries (e.g. CMAKE_SYSTEM_NAME of "Generic", used for GPU and other baremetal targets), CMake's Platform/Generic.cmake sets the global TARGET_SUPPORTS_SHARED_LIBS property to FALSE. Under CMP0164's OLD behavior (the default, since the runtimes set cmake_minimum_required(3.20)), CMake silently demotes SHARED library targets to STATIC archives. libcxx, libcxxabi and libunwind always create their shared target, so after demotion both the shared and static targets emit e.g. "libc++abi.a" and Ninja fails with "multiple rules generate ...". Rather than papering over the collision with a distinct output name, skip creating the shared library targets entirely when the platform does not support them, gating on the TARGET_SUPPORTS_SHARED_LIBS property (left undefined on platforms that do support shared libraries). The few consumers of the shared targets are guarded with TARGET checks so they fall back to the static library or are skipped. Also set policy CMP0164 to NEW so that any future unguarded add_library(... SHARED ...) on an unsupported platform fails at configure time instead of silently producing a colliding static archive. See https://gitlab.kitware.com/cmake/cmake/-/issues/25759. The bodies of the newly-conditional blocks are left at their original indentation to keep this diff minimal. A follow-up commit will fix the indentation. This was mostly AI generated with some comment fixups. Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
2026-06-29 07:53:09 -08:00
# On platforms that don't support shared library targets
# (e.g. CMAKE_SYSTEM_NAME of "Generic", used for GPU and other
# baremetal targets), the shared library target is not built at
# all. The global TARGET_SUPPORTS_SHARED_LIBS property is left
# undefined on platforms that do support shared libraries, and only
# set to FALSE on those that don't. See
# https://gitlab.kitware.com/cmake/cmake/-/issues/25759.
get_property(LIBCXXABI_TARGET_SUPPORTS_SHARED_LIBS GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS)
if(NOT DEFINED LIBCXXABI_TARGET_SUPPORTS_SHARED_LIBS OR LIBCXXABI_TARGET_SUPPORTS_SHARED_LIBS)
set(LIBCXXABI_SUPPORTS_SHARED_LIBRARY ON)
else()
set(LIBCXXABI_SUPPORTS_SHARED_LIBRARY OFF)
endif()
[runtimes] Add the ability to customize the output name of libc++, libc++abi and libunwind We already had the ability to do that for libc++.dylib, so this only adds consistency for all the runtime libraries. This should allow working around difficulties on AIX as described in https://llvm.org/D134221. Differential Revision: https://reviews.llvm.org/D135669
2022-10-11 06:05:56 -08:00
set(LIBCXXABI_SHARED_OUTPUT_NAME "c++abi" CACHE STRING "Output name for the shared libc++abi runtime library.")
set(LIBCXXABI_STATIC_OUTPUT_NAME "c++abi" CACHE STRING "Output name for the static libc++abi runtime library.")
[libc++] Fix a few incorrect CMake configuration options This patch fixes a few CMake options that were set using incorrect mechanisms. CMake's man page for the -D <var>=<value> option states: If a command in the project sets the type to PATH or FILEPATH, then the <value> will be converted to an absolute path. That's not what we want for most of the paths we have as configuration options. Otherwise, using -D to set the configuration option results in an absolute path being used, which breaks things. option() denotes a boolean variable, but what was desired was a string/list variable. Fix this to prevent cmake from changing any non-empty user provided values to 'ON'. Differential Revision: https://reviews.llvm.org/D157926
2023-08-14 14:14:02 -08:00
set(LIBCXXABI_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1" CACHE STRING "Path to install the libc++abi headers at.")
[libcxxabi] Copy headers into build location Prior to D120727, the libcxx build was responsible for copying libcxxabi headers into the right location, both in the build and install trees, but now it's the responsibility of the libcxxabi build. While the build already did the right thing for the install tree, it wouldn't copy headers into the build tree, resulting in errors when trying to use the just built toolchain as is the case in the runtimes build when building compiler-rt runtimes. Differential Revision: https://reviews.llvm.org/D125597
2022-05-13 18:23:52 -08:00
Revert "[libc++] Stop copying headers to the build directory (#115380)" This reverts commit 428c8767ae997b0f726c0b40160ea8172551babf. Breaks sanitizer build: https://lab.llvm.org/buildbot/#/builders/51/builds/9056
2025-01-14 09:23:07 -09:00
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LIBCXXABI_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
else()
set(LIBCXXABI_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
endif()
Missed part of D16545 (static lib testing) http://reviews.llvm.org/D16545 llvm-svn: 271388
2016-06-01 04:50:30 -08:00
set(LIBCXXABI_LIBCXX_LIBRARY_PATH "" CACHE PATH "The path to libc++ library.")
[libc++abi] Introduce a LIBCXXABI_LIBRARY_VERSION option That option controls the 'VERSION' attribute of the libc++abi shared library, which in turn controls the name of the actual dylib being produced. llvm-svn: 373949
2019-10-07 11:22:04 -08:00
set(LIBCXXABI_LIBRARY_VERSION "1.0" CACHE STRING
"Version of libc++abi. This will be reflected in the name of the shared \
library produced. For example, -DLIBCXXABI_LIBRARY_VERSION=x.y will \
result in the library being named libc++abi.x.y.dylib, along with the \
usual symlinks pointing to that.")
Add lit configs for libcxxabi tests. This makes running libcxxabi tests on Linux _much_ easier. Adds a check-libcxxabi target to cmake. Also defaults to building a dynamic libc++abi. This is so that the default options still test the libc++abi that is being built. There are two problems with testing a static libc++abi. In the case of a standalone build, the tests will link the system's libc++, which might not have been built against our libc++abi. In the case of an in tree build, libc++ will prefer a dynamic libc++abi from the system over a static libc++abi from the output directory. llvm-svn: 212672
2014-07-09 18:20:11 -08:00
# Default to building a shared library so that the default options still test
[runtimes][NFC] Remove dead code for Standalone builds Standalone builds have been deprecated and then removed for a while now. Trying to use standalone builds leads to a fatal CMake error, so this code is all dead. Remove it to clean things up. Differential Revision: https://reviews.llvm.org/D125561
2022-05-13 08:15:15 -08:00
# the libc++abi that is being built. The problem with testing a static libc++abi
# is that libc++ will prefer a dynamic libc++abi from the system over a static
# libc++abi from the output directory.
Add lit configs for libcxxabi tests. This makes running libcxxabi tests on Linux _much_ easier. Adds a check-libcxxabi target to cmake. Also defaults to building a dynamic libc++abi. This is so that the default options still test the libc++abi that is being built. There are two problems with testing a static libc++abi. In the case of a standalone build, the tests will link the system's libc++, which might not have been built against our libc++abi. In the case of an in tree build, libc++ will prefer a dynamic libc++abi from the system over a static libc++abi from the output directory. llvm-svn: 212672
2014-07-09 18:20:11 -08:00
option(LIBCXXABI_ENABLE_SHARED "Build libc++abi as a shared library." ON)
[libcxxabi] Build both static and shared versions of libc++abi by default. Summary: This patch builds both static and shared versions of libc++abi by default. It adds/repurposes the following cmake options: * `LIBCXXABI_ENABLE_SHARED`: Enable/disable building the shared library. (Previously using `OFF` would build the static library instead) * `LIBCXXABI_ENABLE_STATIC`: Enable/disable building the static library. This patch also re-purposes the CMake target `cxxabi` to be a meta-target for `cxxabi_shared` and `cxxabi_static`. This could potentially break other builds that depend on `cxxabi` being a library target. We will need to apply a patch to libc++'s CMake before committing this change. Running the tests is still only supported when the shared version is built. Support for running the tests against the static library will come in another patch. Reviewers: jroelofs, mclow.lists, danalbert, compnerd Reviewed By: danalbert, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8013 llvm-svn: 231075
2015-03-03 06:59:09 -09:00
option(LIBCXXABI_ENABLE_STATIC "Build libc++abi as a static library." ON)
[CMake] Don't use LIBCXXABI_ENABLE_STATIC option before its declared Summary: rL337867 introduced two new cmake_dependent_option options: - LIBCXXABI_INSTALL_STATIC_LIBRARY - LIBCXXABI_INSTALL_SHARED_LIBRARY They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED and so therefore need to (it seems) come after the declaration of these two options. Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits Differential Revision: https://reviews.llvm.org/D49825 llvm-svn: 337982
2018-07-25 15:13:00 -08:00
cmake_dependent_option(LIBCXXABI_INSTALL_STATIC_LIBRARY
"Install the static libc++abi library." ON
"LIBCXXABI_ENABLE_STATIC;LIBCXXABI_INSTALL_LIBRARY" OFF)
cmake_dependent_option(LIBCXXABI_INSTALL_SHARED_LIBRARY
"Install the shared libc++abi library." ON
"LIBCXXABI_ENABLE_SHARED;LIBCXXABI_INSTALL_LIBRARY" OFF)
Reland "[CMake] Support statically linking dependencies only to shared or static library" This is a reland of commit r337668. llvm-svn: 337814
2018-07-23 23:06:17 -08:00
cmake_dependent_option(LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_STATIC_LIBRARY
"Statically link the LLVM unwinder to static library" ON
[runtimes] Fix the build of merged ABI/unwinder libraries Also, add a CI job that tests this configuration. The exact configuration is that we build a shared libc++ and merge objects for the ABI library and the unwinder library into it. Differential Revision: https://reviews.llvm.org/D125903
2022-05-18 08:05:45 -08:00
"LIBCXXABI_ENABLE_STATIC_UNWINDER" OFF)
Reland "[CMake] Support statically linking dependencies only to shared or static library" This is a reland of commit r337668. llvm-svn: 337814
2018-07-23 23:06:17 -08:00
cmake_dependent_option(LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY
"Statically link the LLVM unwinder to shared library" ON
[runtimes] Fix the build of merged ABI/unwinder libraries Also, add a CI job that tests this configuration. The exact configuration is that we build a shared libc++ and merge objects for the ABI library and the unwinder library into it. Differential Revision: https://reviews.llvm.org/D125903
2022-05-18 08:05:45 -08:00
"LIBCXXABI_ENABLE_STATIC_UNWINDER" OFF)
Reland "[CMake] Support statically linking dependencies only to shared or static library" This is a reland of commit r337668. llvm-svn: 337814
2018-07-23 23:06:17 -08:00
[libcxxabi] Clean up macro usage. Convention in libcxxabi is to use !defined(FOO) not !FOO. Differential Revision: https://reviews.llvm.org/D30459 llvm-svn: 296612
2017-03-01 02:42:01 -09:00
option(LIBCXXABI_BAREMETAL "Build libc++abi for baremetal targets." OFF)
# The default terminate handler attempts to demangle uncaught exceptions, which
# causes extra I/O and demangling code to be pulled in.
option(LIBCXXABI_SILENT_TERMINATE "Set this to make the terminate handler default to a silent alternative" OFF)
[libc++abi] Add an option to avoid demangling in terminate. We've been using this patch in Android so we can avoid including the demangler in libc++.so. It comes with a rather large cost in RSS and isn't commonly needed. Reviewed By: #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D88189
2021-01-21 12:27:14 -09:00
option(LIBCXXABI_NON_DEMANGLING_TERMINATE "Set this to make the terminate handler
avoid demangling" OFF)
[libcxxabi] Clean up macro usage. Convention in libcxxabi is to use !defined(FOO) not !FOO. Differential Revision: https://reviews.llvm.org/D30459 llvm-svn: 296612
2017-03-01 02:42:01 -09:00
[libcxxabi] Build both static and shared versions of libc++abi by default. Summary: This patch builds both static and shared versions of libc++abi by default. It adds/repurposes the following cmake options: * `LIBCXXABI_ENABLE_SHARED`: Enable/disable building the shared library. (Previously using `OFF` would build the static library instead) * `LIBCXXABI_ENABLE_STATIC`: Enable/disable building the static library. This patch also re-purposes the CMake target `cxxabi` to be a meta-target for `cxxabi_shared` and `cxxabi_static`. This could potentially break other builds that depend on `cxxabi` being a library target. We will need to apply a patch to libc++'s CMake before committing this change. Running the tests is still only supported when the shared version is built. Support for running the tests against the static library will come in another patch. Reviewers: jroelofs, mclow.lists, danalbert, compnerd Reviewed By: danalbert, compnerd Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8013 llvm-svn: 231075
2015-03-03 06:59:09 -09:00
if (NOT LIBCXXABI_ENABLE_SHARED AND NOT LIBCXXABI_ENABLE_STATIC)
message(FATAL_ERROR "libc++abi must be built as either a shared or static library.")
endif()
Add lit configs for libcxxabi tests. This makes running libcxxabi tests on Linux _much_ easier. Adds a check-libcxxabi target to cmake. Also defaults to building a dynamic libc++abi. This is so that the default options still test the libc++abi that is being built. There are two problems with testing a static libc++abi. In the case of a standalone build, the tests will link the system's libc++, which might not have been built against our libc++abi. In the case of an in tree build, libc++ will prefer a dynamic libc++abi from the system over a static libc++abi from the output directory. llvm-svn: 212672
2014-07-09 18:20:11 -08:00
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows (In the case of libunwind, the cmake option is called LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as LIBCXX_HERMETIC_STATIC_LIBRARY and LIBCXXABI_HERMETIC_STATIC_LIBRARY.) Previously, the same issue was dealt with by setting a project wide define (_LIBUNWIND_HIDE_SYMBOLS, _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static library. If building both static and shared at the same time, this wasn't set, and the static library would contain dllexport directives. The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake options only apply the defines to the static library in the build, even if building both static and shared at the same time. (This could only be done use after the object libraries were enabled, as a shared libcxx needs libcxxabi object files built with dllexports included.) This allows removing inelegant code for deciding how to build the libcxxabi static library and a TODO comment that suggested that users should need to start setting an option, which they shouldn't need to. Finally, this gets rid of two XFAILs in tests. Differential Revision: https://reviews.llvm.org/D125715
2022-04-09 12:40:07 -08:00
set(LIBCXXABI_HERMETIC_STATIC_LIBRARY_DEFAULT OFF)
if (WIN32)
set(LIBCXXABI_HERMETIC_STATIC_LIBRARY_DEFAULT ON)
endif()
[libcxxabi] Support building hermetic static library This is useful when the static libc++abi library is being linked into shared libraries that may be used in with other shared libraries that use different C++ library. We want to avoid avoid exporting libc++abi or libc++ symbols in those cases. This achieved by a new CMake option which can be enabled by libc++abi vendors as needed. Differential Revision: https://reviews.llvm.org/D56026 llvm-svn: 352017
2019-01-23 18:18:29 -09:00
option(LIBCXXABI_HERMETIC_STATIC_LIBRARY
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows (In the case of libunwind, the cmake option is called LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as LIBCXX_HERMETIC_STATIC_LIBRARY and LIBCXXABI_HERMETIC_STATIC_LIBRARY.) Previously, the same issue was dealt with by setting a project wide define (_LIBUNWIND_HIDE_SYMBOLS, _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static library. If building both static and shared at the same time, this wasn't set, and the static library would contain dllexport directives. The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake options only apply the defines to the static library in the build, even if building both static and shared at the same time. (This could only be done use after the object libraries were enabled, as a shared libcxx needs libcxxabi object files built with dllexports included.) This allows removing inelegant code for deciding how to build the libcxxabi static library and a TODO comment that suggested that users should need to start setting an option, which they shouldn't need to. Finally, this gets rid of two XFAILs in tests. Differential Revision: https://reviews.llvm.org/D125715
2022-04-09 12:40:07 -08:00
"Do not export any symbols from the static library." ${LIBCXXABI_HERMETIC_STATIC_LIBRARY_DEFAULT})
[libcxxabi] Support building hermetic static library This is useful when the static libc++abi library is being linked into shared libraries that may be used in with other shared libraries that use different C++ library. We want to avoid avoid exporting libc++abi or libc++ symbols in those cases. This achieved by a new CMake option which can be enabled by libc++abi vendors as needed. Differential Revision: https://reviews.llvm.org/D56026 llvm-svn: 352017
2019-01-23 18:18:29 -09:00
[runtimes] Simplify testing configurations on GCC by using -nostdlib++ (#67021) Since GCC now supports -nostdlib++, we can remove some complexity in the test configurations and do the same as Clang. However, we can't fully remove the GCC test configuration for libc++ because we apparently need to explicitly link against libm for some tests to work.
2023-09-21 13:21:24 -08:00
if(MINGW)
[libc++abi] Use from-scratch testing configs for libc++abi by default Like we have been doing for libc++ for a while now, start using from-scratch testing configurations for libc++abi. As a fly-by fix, remove the LIBCXXABI_NO_TIMER macro, which was defined but never used. Differential Revision: https://reviews.llvm.org/D125242
2022-05-09 07:54:10 -08:00
set(LIBCXXABI_DEFAULT_TEST_CONFIG "llvm-libc++abi-mingw.cfg.in")
elseif(WIN32) # clang-cl
if (LIBCXXABI_ENABLE_SHARED)
set(LIBCXXABI_DEFAULT_TEST_CONFIG "llvm-libc++abi-shared-clangcl.cfg.in")
else()
set(LIBCXXABI_DEFAULT_TEST_CONFIG "llvm-libc++abi-static-clangcl.cfg.in")
endif()
else()
if (LIBCXXABI_ENABLE_SHARED)
set(LIBCXXABI_DEFAULT_TEST_CONFIG "llvm-libc++abi-shared.cfg.in")
else()
set(LIBCXXABI_DEFAULT_TEST_CONFIG "llvm-libc++abi-static.cfg.in")
endif()
endif()
set(LIBCXXABI_TEST_CONFIG "${LIBCXXABI_DEFAULT_TEST_CONFIG}" CACHE STRING
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-29 11:26:05 -08:00
"The path to the Lit testing configuration to use when running the tests.
[libc++abi][ci] Add a from-scratch config for libc++abi on Apple/system I came across an issue where since we build the library for Apple with the install name directory being /usr/lib, which means that if we don't run the tests with DYLD_LIBRARY_PATH, we'll end up loading the system-provided libc++abi when running the tests. That wreaks havoc. Instead of fixing it in the legacy config file, this commit introduces an Apple libc++abi config file that does the right thing. Differential Revision: https://reviews.llvm.org/D111279
2021-10-12 13:45:45 -08:00
If a relative path is provided, it is assumed to be relative to '<monorepo>/libcxxabi/test/configs'.")
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-29 11:26:05 -08:00
if (NOT IS_ABSOLUTE "${LIBCXXABI_TEST_CONFIG}")
[libc++abi][ci] Add a from-scratch config for libc++abi on Apple/system I came across an issue where since we build the library for Apple with the install name directory being /usr/lib, which means that if we don't run the tests with DYLD_LIBRARY_PATH, we'll end up loading the system-provided libc++abi when running the tests. That wreaks havoc. Instead of fixing it in the legacy config file, this commit introduces an Apple libc++abi config file that does the right thing. Differential Revision: https://reviews.llvm.org/D111279
2021-10-12 13:45:45 -08:00
set(LIBCXXABI_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/configs/${LIBCXXABI_TEST_CONFIG}")
[runtimes] Allow FOO_TEST_CONFIG to be a relative path That makes it possible to store that value in a CMake cache if needed. Differential Revision: https://reviews.llvm.org/D110843
2021-09-29 11:26:05 -08:00
endif()
[runtimes] Print the testing configuration in use in libunwind and libc++abi We do it for libc++, and it's rather useful for debugging e.g. CI.
2022-05-11 06:16:29 -08:00
message(STATUS "Using libc++abi testing configuration: ${LIBCXXABI_TEST_CONFIG}")
[runtimes] Allow passing Lit parameters through CMake This allows passing parameters to the test suites without using LLVM_LIT_ARGS. The problem is that we sometimes want to set some Lit arguments on the CMake command line, but the Lit parameters in a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS, the command-line entry overrides the cache one, and the parameters set by the cache are ignored. This fixes a current issue with the build bots that they completely ignore the 'std' param set by Lit, because other Lit arguments are provided via LLVM_LIT_ARGS on the CMake command-line.
2020-07-09 07:54:09 -08:00
set(LIBCXXABI_TEST_PARAMS "" CACHE STRING
"A list of parameters to run the Lit test suite with.")
[libc++abi] Allow specifying custom Lit config files This is the libc++abi counterpart of 0c66af970c80.
2020-06-25 07:46:00 -08:00
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
#===============================================================================
# Configure System
#===============================================================================
# Add path for custom modules
set(CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
${CMAKE_MODULE_PATH}
)
[libc++] Fix a few incorrect CMake configuration options This patch fixes a few CMake options that were set using incorrect mechanisms. CMake's man page for the -D <var>=<value> option states: If a command in the project sets the type to PATH or FILEPATH, then the <value> will be converted to an absolute path. That's not what we want for most of the paths we have as configuration options. Otherwise, using -D to set the configuration option results in an absolute path being used, which breaks things. option() denotes a boolean variable, but what was desired was a string/list variable. Fix this to prevent cmake from changing any non-empty user provided values to 'ON'. Differential Revision: https://reviews.llvm.org/D157926
2023-08-14 14:14:02 -08:00
set(LIBCXXABI_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE STRING
[libc++][libc++abi][libunwind] Dedup install path var definitions In D116873 I did this for libunwind prior to defining a new install path variable. But I think the change is good on its own, and libc++{,abi} could also use it. libc++ needed the base header var defined above the conditional part to use it for the prefi+ed headers in the non-target-specific case. For consistency, I therefore put the unconditional ones above for all 3 libs, which is why I touched the libunwind code (seeing that it had the core change already) Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116988
2022-01-10 18:03:21 -09:00
"Path where built libc++abi runtime libraries should be installed.")
[Runtimes] Introduce variables containing resource dir paths (#177953) Introduce common infrastructure for runtimes that determines compiler resource path locations. These variables introduced are: * RUNTIMES_OUTPUT_RESOURCE_DIR * RUNTIMES_INSTALL_RESOURCE_PATH That contain the location for the compiler resource path (typically `lib/clang/<version>`) in the build tree and the install tree (the latter relative to CMAKE_INSTALL_PREFIX). Additionally, define * RUNTIMES_OUTPUT_RESOURCE_LIB_DIR * RUNTIMES_INSTALL_RESOURCE_LIB_PATH as for the location of clang/flang version-locked libraries (typically `lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE` and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from flang-rt and initially becomes its only user. Refactored out of #171610 as requested [here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481). Extracted `get_runtimes_target_libdir_common` from compiler-rt as requested [here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634). Added TODO comments to all runtimes as requested [here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
2026-04-02 02:32:14 -08:00
# TODO: Use common runtimes infrastructure for output and install paths
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-27 19:11:52 -08:00
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 10:48:45 -08:00
set(LIBCXXABI_TARGET_SUBDIR ${LLVM_DEFAULT_TARGET_TRIPLE})
if(LIBCXXABI_LIBDIR_SUBDIR)
string(APPEND LIBCXXABI_TARGET_SUBDIR /${LIBCXXABI_LIBDIR_SUBDIR})
endif()
[cmake] Normalize TARGET_SUBDIR paths (#138524) Some code paths normalize ".." and thus don't create the directory. But some execute in a shell thus requiring the directory to exist to be able to take the parent directory. This patch normalizes all the `TARGET_SUBDIR` variables to avoid this issue.
2025-05-12 11:59:39 -08:00
cmake_path(NORMAL_PATH LIBCXXABI_TARGET_SUBDIR)
[libcxxabi] Use cxx-headers target to consume libcxx headers Rather than including libc++ include dir, use the cxx-headers target. Differential Revision: https://reviews.llvm.org/D98367
2021-03-10 10:21:41 -09:00
set(LIBCXXABI_HEADER_DIR ${LLVM_BINARY_DIR})
[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 10:48:45 -08:00
set(LIBCXXABI_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LIBCXXABI_TARGET_SUBDIR})
set(LIBCXXABI_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LIBCXXABI_TARGET_SUBDIR} CACHE STRING
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 14:36:47 -08:00
"Path where built libc++abi libraries should be installed.")
[libcxxabi][cmake] Account for LIBCXXABI_TARGET_SUBDIR in test config (#138527) This makes the logic and code structure match that of libc++, which handles this case (i.e. the target subdirectory being changed). The `%{target}` substitution from libc++ is removed as libc++abi's config seems to be the only place it's used.
2025-07-03 01:07:25 -08:00
set(LIBCXXABI_INSTALL_INCLUDE_TARGET_DIR "${CMAKE_INSTALL_INCLUDEDIR}/${LIBCXXABI_TARGET_SUBDIR}/c++/v1" CACHE STRING
"Path where target-specific libc++abi headers should be installed.")
[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 10:48:45 -08:00
unset(LIBCXXABI_TARGET_SUBDIR)
[libcxxabi][CMake] Set library dir when built under runtimes/ This will put libraries into the build root's lib/ directory by default. Differential Revision: https://reviews.llvm.org/D32735 llvm-svn: 302118
2017-05-03 22:04:49 -08:00
else()
[libc++][libc++abi][libunwind] Dedup install path var definitions In D116873 I did this for libunwind prior to defining a new install path variable. But I think the change is good on its own, and libc++{,abi} could also use it. libc++ needed the base header var defined above the conditional part to use it for the prefi+ed headers in the non-target-specific case. For consistency, I therefore put the unconditional ones above for all 3 libs, which is why I touched the libunwind code (seeing that it had the core change already) Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116988
2022-01-10 18:03:21 -09:00
if(LLVM_LIBRARY_OUTPUT_INTDIR)
set(LIBCXXABI_HEADER_DIR ${LLVM_BINARY_DIR})
set(LIBCXXABI_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
else()
set(LIBCXXABI_HEADER_DIR ${CMAKE_BINARY_DIR})
Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too" This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18 18:44:46 -08:00
set(LIBCXXABI_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXXABI_LIBDIR_SUFFIX})
[libc++][libc++abi][libunwind] Dedup install path var definitions In D116873 I did this for libunwind prior to defining a new install path variable. But I think the change is good on its own, and libc++{,abi} could also use it. libc++ needed the base header var defined above the conditional part to use it for the prefi+ed headers in the non-target-specific case. For consistency, I therefore put the unconditional ones above for all 3 libs, which is why I touched the libunwind code (seeing that it had the core change already) Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D116988
2022-01-10 18:03:21 -09:00
endif()
[libc++] Fix a few incorrect CMake configuration options This patch fixes a few CMake options that were set using incorrect mechanisms. CMake's man page for the -D <var>=<value> option states: If a command in the project sets the type to PATH or FILEPATH, then the <value> will be converted to an absolute path. That's not what we want for most of the paths we have as configuration options. Otherwise, using -D to set the configuration option results in an absolute path being used, which breaks things. option() denotes a boolean variable, but what was desired was a string/list variable. Fix this to prevent cmake from changing any non-empty user provided values to 'ON'. Differential Revision: https://reviews.llvm.org/D157926
2023-08-14 14:14:02 -08:00
set(LIBCXXABI_INSTALL_LIBRARY_DIR lib${LIBCXXABI_LIBDIR_SUFFIX} CACHE STRING
Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all This is a second attempt at D101497, which landed as 9a9bc76c0eb72f0f2732c729a460abbd5239c2e3 but had to be reverted in 8cf7ddbdd4e5af966a369e170c73250f2e3920e7. This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to "/bin" not "bin" as intended and as was originally. One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty, defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach. But, I think it is more ergonomic to allow those project-specific paths to be relative the global ones. Also, making install paths absolute by default inhibits the proper behavior of functions like `GNUInstallDirs_get_absolute_install_dir` which make relative install paths absolute in a more complicated way. Given all this, I will define a function like the one asked for in https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a similar use-case). --- Original message: Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for complier-rt, just use it to define variables for the subdirs which themselves are used. This preserves compatibility, but later on we might consider getting rid of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the subdir variables directly. --- There was a seaming bug where the (non-Apple) per-target libdir was `${target}` not `lib/${target}`. I suspect that has to do with the docs on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no longer true, so I just went ahead and fixed it, allowing me to define fewer and more sensible variables. That last part should be the only behavior changes; everything else should be a pure refactoring. --- I added some documentation of these variables too. In particular, I wanted to highlight the gotcha where `-DSomeCachePath=...` without the `:PATH` will lead CMake to make the path absolute. See [1] for discussion of the problem, and [2] for the brief official documentation they added as a result. [1]: https://cmake.org/pipermail/cmake/2015-March/060204.html [2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options In 38b2dec37ee735d5409148e71ecba278caf0f969 the problem was somewhat misidentified and so `:STRING` was used, but `:PATH` is better as it sets the correct type from the get-go. --- D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands, it should be feasible to follow both of these up with a simple patch for compiler-rt analogous to the one for libcxx. Reviewed By: phosek, #libc_abi, #libunwind Differential Revision: https://reviews.llvm.org/D105765
2021-04-28 14:36:47 -08:00
"Path where built libc++abi libraries should be installed.")
[libcxxabi][cmake] Account for LIBCXXABI_TARGET_SUBDIR in test config (#138527) This makes the logic and code structure match that of libc++, which handles this case (i.e. the target subdirectory being changed). The `%{target}` substitution from libc++ is removed as libc++abi's config seems to be the only place it's used.
2025-07-03 01:07:25 -08:00
set(LIBCXXABI_INSTALL_INCLUDE_TARGET_DIR "${LIBCXXABI_INSTALL_INCLUDE_DIR}" CACHE STRING
"Path where target-specific libc++abi headers should be installed.")
[libcxxabi][CMake] Set library dir when built under runtimes/ This will put libraries into the build root's lib/ directory by default. Differential Revision: https://reviews.llvm.org/D32735 llvm-svn: 302118
2017-05-03 22:04:49 -08:00
endif()
[cmake/multilib] Teach libc++abi's CMake build to support multilib libdir suffixes like 'lib64' or 'lib32'. This support is currently very rhudimentary. We define a variable LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be directly set as a cached variable to control the multilib suffix used. When building libc++abi within a larger LLVM build, it is hard wired to whatever LLVM libdir suffix has been selected. If this doesn't work for someone, just let me know. I'm happy to change it. Unfortunately, libc++abi's lit setup made this somewhat problematic to change. It was setting variables up in a way that caused the resulting build to not work with lit at all. To fix that, I've moved some variables around in the CMake build to more closely match where and how they are defined in the libc++ CMake build. This includes specifically defining a library root variable in the CMake build where the libdir suffix can be applied, and then using that rather than re-computing it from the object directory in the lit config. This is essentially new functionality for libc++abi so I don't expect it to have any impact for folks until they start setting these variables. However, I know libc++abi is built in a diverse set of environments so just let me know if this causes you any problems. llvm-svn: 224927
2014-12-29 03:22:04 -09:00
Respect LIBCXXABI_LIBDIR_SUFFIX before an install Prior to this patch, setting LIBCXXABI_LIBDIR_SUFFIX would confuse the check-libcxxabi target. libc++abi.* would get output to lib instead of lib${LIBCXXABI_LIBDIR_SUFFIX}, but the tests would look in the suffixed directory. Now, we match what libcxx does, and set the CMAKE_*_OUTPUT_DIRECTORY to the LIBRARY_DIR. http://reviews.llvm.org/D17410 llvm-svn: 266611
2016-04-18 05:30:38 -08:00
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LIBCXXABI_LIBRARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIBCXXABI_LIBRARY_DIR})
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LIBCXXABI_LIBRARY_DIR})
Respect LIBCXXABI_LIBDIR_SUFFIX before an install Prior to this patch, setting LIBCXXABI_LIBDIR_SUFFIX would confuse the check-libcxxabi target. libc++abi.* would get output to lib instead of lib${LIBCXXABI_LIBDIR_SUFFIX}, but the tests would look in the suffixed directory. Now, we match what libcxx does, and set the CMAKE_*_OUTPUT_DIRECTORY to the LIBRARY_DIR. http://reviews.llvm.org/D17410 llvm-svn: 266611
2016-04-18 05:30:38 -08:00
[runtimes][NFC] Remove dead code for Standalone builds Standalone builds have been deprecated and then removed for a while now. Trying to use standalone builds leads to a fatal CMake error, so this code is all dead. Remove it to clean things up. Differential Revision: https://reviews.llvm.org/D125561
2022-05-13 08:15:15 -08:00
# By default, libcxx and libcxxabi share a library directory.
Missed part of D16545 (static lib testing) http://reviews.llvm.org/D16545 llvm-svn: 271388
2016-06-01 04:50:30 -08:00
if (NOT LIBCXXABI_LIBCXX_LIBRARY_PATH)
set(LIBCXXABI_LIBCXX_LIBRARY_PATH "${LIBCXXABI_LIBRARY_DIR}" CACHE PATH
[libcxxabi] Allow tests to link with static libc++abi/libc++ even if the shared version is present Summary: Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](https://github.com/llvm/llvm-project/blob/54c522420347e58aa7bae1892cf5c5672b57c875/libcxxabi/CMakeLists.txt#L503-L519). This change allows specifying the version of the library for tests to link with. This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically. Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries. It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way. Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig Subscribers: mgorny, christof, ldionne, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71894
2019-12-26 00:28:39 -09:00
"The path to libc++ library." FORCE)
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23092 llvm-svn: 278030
2016-08-08 09:59:02 -08:00
endif()
[libcxxabi] Allow target flags to affect configuration tests. Summary: This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`. Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed. Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20886 llvm-svn: 271470
2016-06-01 18:18:31 -08:00
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
# Declare libc++abi configuration variables.
# They are intended for use as follows:
# LIBCXXABI_C_FLAGS: General flags for both the c++ compiler and linker.
# LIBCXXABI_CXX_FLAGS: General flags for both the c++ compiler and linker.
# LIBCXXABI_COMPILE_FLAGS: Compile only flags.
# LIBCXXABI_LINK_FLAGS: Linker only flags.
# LIBCXXABI_LIBRARIES: libraries libc++abi is linked to.
[libcxxabi] Allow target flags to affect configuration tests. Summary: This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`. Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed. Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20886 llvm-svn: 271470
2016-06-01 18:18:31 -08:00
Add -funwind-tables to CMAKE_C_FLAGS. Without -funwind-tables, the compiler won't generate the unwinding table for these C functions. However, the functions in libunwind, such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace. llvm-svn: 226823
2015-01-22 04:39:08 -09:00
set(LIBCXXABI_C_FLAGS "")
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
set(LIBCXXABI_CXX_FLAGS "")
set(LIBCXXABI_COMPILE_FLAGS "")
set(LIBCXXABI_LINK_FLAGS "")
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
set(LIBCXXABI_LIBRARIES "")
[runtimes] Improve the documentation for LIBCXX_ADDITIONAL_COMPILE_FLAGS (#112733) This clarifies how that option is meant to be used to avoid confusion. As a drive-by, also fix an incorrect usage in the recently-added GPU caches.
2024-10-17 12:17:40 -08:00
set(LIBCXXABI_ADDITIONAL_COMPILE_FLAGS "" CACHE STRING "See documentation LIBCXX_ADDITIONAL_COMPILE_FLAGS")
[SystemZ][z/OS] Add ASCII and 32-bit variants for libc++. This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces: # ASCII version of libc++ named as libc++_a.so # Script to rename DLL name inside the generated side deck # Various names for dataset members where DLL libraries and their side decks will reside # Add the following options: - LIBCXX_SHARED_OUTPUT_NAME - LIBCXX_ADDITIONAL_COMPILE_FLAGS - LIBCXX_ADDITIONAL_LIBRARIES - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS - LIBCXXABI_ADDITIONAL_LIBRARIES **Background and rational of this patch** The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name. If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL. Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D118503
2022-10-03 13:41:58 -08:00
set(LIBCXXABI_ADDITIONAL_LIBRARIES "" CACHE STRING
"Additional libraries libc++abi is linked to which can be provided in cache")
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
# Include macros for adding and removing libc++abi flags.
include(HandleLibcxxabiFlags)
#===============================================================================
# Setup Compiler Flags
#===============================================================================
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
[libcxxabi] Allow target flags to affect configuration tests. Summary: This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`. Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed. Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20886 llvm-svn: 271470
2016-06-01 18:18:31 -08:00
# Configure target flags
[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537) A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20 08:45:41 -08:00
if ("${CMAKE_SYSTEM_NAME}" MATCHES "AIX")
[runtimes] Remove add_target_flags* functions and use add_flags* instead Reviewed By: phosek, #libunwind, #libc, #libc_abi Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D144398
2023-02-20 06:47:34 -09:00
add_flags_if_supported("-mdefault-visibility-export-mapping=explicit")
[libcxx][AIX] Switch build compiler to clang This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose). Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne Differential Revision: https://reviews.llvm.org/D127470
2022-06-13 17:44:58 -08:00
set(CMAKE_AIX_EXPORT_ALL_SYMBOLS OFF)
endif()
[SystemZ][z/OS] Add ASCII and 32-bit variants for libc++. This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces: # ASCII version of libc++ named as libc++_a.so # Script to rename DLL name inside the generated side deck # Various names for dataset members where DLL libraries and their side decks will reside # Add the following options: - LIBCXX_SHARED_OUTPUT_NAME - LIBCXX_ADDITIONAL_COMPILE_FLAGS - LIBCXX_ADDITIONAL_LIBRARIES - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS - LIBCXXABI_ADDITIONAL_LIBRARIES **Background and rational of this patch** The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a member of a dataset then the DLL name in the side deck is the member name. If CMake could deal with z/OS datasets we could use -o that points to a dataset member name, but this does not seem to work so we have to produce a USS file as the DLL and then copy the content of the produced side deck to a dataset as well as rename the USS file name in the side deck to a dataset member name that corresponds to that DLL. Reviewed By: muiez, SeanP, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D118503
2022-10-03 13:41:58 -08:00
add_library_flags("${LIBCXXABI_ADDITIONAL_LIBRARIES}")
[libcxx][AIX] Switch build compiler to clang This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose). Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne Differential Revision: https://reviews.llvm.org/D127470
2022-06-13 17:44:58 -08:00
[libcxxabi] Allow target flags to affect configuration tests. Summary: This patch changes the libc++abi CMake so that it adds certain target flags like '-m32' or '--gcc-toolchain' before including `config-ix.cmake`. Since these flags can affect things like `check_library_exists([...])` they needed to be added before the tests are performed. Additionally this patch adds `LIBCXXABI_BUILD_32_BITS` which defaults to `LLVM_BUILD_32_BITS`. This patch fixes: https://llvm.org/bugs/show_bug.cgi?id=27950 https://llvm.org/bugs/show_bug.cgi?id=27959 Reviewers: danalbert, jroelofs, bcraig, compnerd, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20886 llvm-svn: 271470
2016-06-01 18:18:31 -08:00
# Configure compiler. Must happen after setting the target flags.
include(config-ix)
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
[libcxxabi][libunwind] Support for using LLVM libc (#134893) This generalizes the support added in #99287 renaming the option to RUNTIMES_USE_LIBC and integrating the module into libc++abi and libunwind as well.
2025-07-08 23:48:50 -08:00
include(HandleLibC) # Setup the C library flags
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 00:47:09 -09:00
if (CXX_SUPPORTS_NOSTDINCXX_FLAG)
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
list(APPEND LIBCXXABI_COMPILE_FLAGS -nostdinc++)
[libcxxabi] Prevent cmake from removing our explicit system C++ include paths We build with `-nostdinc++` and add our own header path via `LIBCXXABI_LIBCXX_INCLUDES`. However cmake tried to be clever and if `LIBCXXABI_LIBCXX_INCLUDES` happens to match the compilers system path it will remove the `-I` flag meaning we can't access any C++ headers. Ideally cmake would be able see that we are using `-nostdinc++` and disable this behaviour. Differential Revision: https://reviews.llvm.org/D69973
2019-11-07 13:51:25 -09:00
# cmake 3.14 and above remove system include paths that are explicitly
# passed on the command line. We build with -nostdinc++ and explicitly add
# just the libcxx system include paths with -I on the command line.
# Setting CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES effectively prevents cmake
# from removing these.
# See: https://gitlab.kitware.com/cmake/cmake/issues/19227
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "")
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
# Remove -stdlib flags to prevent them from causing an unused flag warning.
Fix all the CMake code that can only handle -stdlib= but not --stdlib= There are several places in LLVM's CMake setup that try to remove the `stdlib=...` flag from the CMake flags. All this code however only considered the `-stdlib=` variant of the flag but not the alternative spelling with a double dash. This causes that when one adds `--stdlib=...` to the user-provided CMake flags that this gets transformed into just `-` which ends up causing the build system to think it should read the source from stdin (which then lead to very confusing build errors). This just adds the alternative spelling before the`-stdlib=` variant in all these places Reviewed By: ldionne Differential Revision: https://reviews.llvm.org/D87133
2020-10-13 06:05:00 -08:00
string(REPLACE "--stdlib=libc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REPLACE "--stdlib=libstdc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
string(REPLACE "-stdlib=libc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
string(REPLACE "-stdlib=libstdc++" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
endif()
[libc++abi] Build cxxabi with sanitizers (#119612)
2024-12-12 17:03:12 -09:00
function(get_sanitizer_flags OUT_VAR USE_SANITIZER)
set(SANITIZER_FLAGS)
set(USE_SANITIZER "${USE_SANITIZER}")
# NOTE: LLVM_USE_SANITIZER checks for a UNIX like system instead of MSVC.
# But we don't have LLVM_ON_UNIX so checking for MSVC is the best we can do.
if (USE_SANITIZER AND NOT MSVC)
append_flags_if_supported(SANITIZER_FLAGS "-fno-omit-frame-pointer")
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
endif()
if (USE_SANITIZER STREQUAL "Address")
append_flags(SANITIZER_FLAGS "-fsanitize=address")
elseif (USE_SANITIZER STREQUAL "HWAddress")
append_flags(SANITIZER_FLAGS "-fsanitize=hwaddress")
elseif (USE_SANITIZER MATCHES "Memory(WithOrigins)?")
append_flags(SANITIZER_FLAGS -fsanitize=memory)
if (USE_SANITIZER STREQUAL "MemoryWithOrigins")
append_flags(SANITIZER_FLAGS "-fsanitize-memory-track-origins")
endif()
elseif (USE_SANITIZER STREQUAL "Undefined")
append_flags(SANITIZER_FLAGS "-fsanitize=undefined" "-fno-sanitize=vptr,function" "-fno-sanitize-recover=all")
elseif (USE_SANITIZER STREQUAL "Address;Undefined" OR
USE_SANITIZER STREQUAL "Undefined;Address")
append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined" "-fno-sanitize=vptr,function" "-fno-sanitize-recover=all")
elseif (USE_SANITIZER STREQUAL "Thread")
append_flags(SANITIZER_FLAGS -fsanitize=thread)
elseif (USE_SANITIZER STREQUAL "DataFlow")
append_flags(SANITIZER_FLAGS -fsanitize=dataflow)
else()
message(WARNING "Unsupported value of LLVM_USE_SANITIZER: ${USE_SANITIZER}")
endif()
elseif(USE_SANITIZER AND MSVC)
message(WARNING "LLVM_USE_SANITIZER is not supported on this platform.")
endif()
set(${OUT_VAR} "${SANITIZER_FLAGS}" PARENT_SCOPE)
endfunction()
get_sanitizer_flags(SANITIZER_FLAGS "${LLVM_USE_SANITIZER}")
list(APPEND LIBCXXABI_COMPILE_FLAGS ${SANITIZER_FLAGS})
[libc++abi] Default to DLL annotations on Windows `__declspec(dllexport)` and `__declspec(dllimport)` should only be used when building libc++abi as a DLL, but that's the more common use case, so default to adding the annotations and add an option to opt out. Similar to r282449, which made the corresponding change for libc++. Differential Revision: https://reviews.llvm.org/D24945 llvm-svn: 282470
2016-09-26 19:44:09 -08:00
# Let the library headers know they are currently being used to build the
# library.
add_definitions(-D_LIBCXXABI_BUILDING_LIBRARY)
[libcxxabi] Build all of libcxxabi with _LIBCPP_BUILDING_LIBRARY defined Various definitions from libcxx need to be set in the same way as if building libcxx itself. Differential Revision: https://reviews.llvm.org/D90476
2020-10-30 09:11:23 -08:00
# libcxxabi needs to, for various reasons, include the libcpp headers as if
# it is being built as part of libcxx.
add_definitions(-D_LIBCPP_BUILDING_LIBRARY)
[libc++] Introduce the notion of a minimum header version (#166074) Introducing the notion of a minimum header version has multiple benefits. It allows us to merge a bunch of ABI macros into a single one. This makes configuring the library significantly easier, since, for a stable ABI, you only need to know which version you started distributing the library with, instead of checking which ABI flags have been introduced at what point. For platforms which have a moving window of the minimum version a program has been compiled against, this also makes it simple to remove symbols from the dylib when they can't be used by any program anymore.
2026-01-09 01:58:29 -09:00
add_definitions(-D_LIBCPP_AVAILABILITY_MINIMUM_HEADER_VERSION=${LIBCXXABI_AVAILABILITY_MINIMUM_HEADER_VERSION})
[libcxxabi] Build all of libcxxabi with _LIBCPP_BUILDING_LIBRARY defined Various definitions from libcxx need to be set in the same way as if building libcxx itself. Differential Revision: https://reviews.llvm.org/D90476
2020-10-30 09:11:23 -08:00
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
# Get feature flags.
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
add_compile_flags_if_supported(-fstrict-aliasing)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
[libcxxabi] Introduce a -fno-exceptions libc++abi libary variant Currently there is only support for a -fno-exceptions libc++ build. This is problematic for functions such as std::terminate() which are defined in libc++abi and using any of those functions throws away most of the benefits of using -fno-exceptions (code-size). This patch introduces a -fno-exceptions libc++abi build to address this issue. This new variant of libc++abi cannot be linked against any with-exceptions code as some symbols necessary for handling exceptions are missing in this library. Differential revision: http://reviews.llvm.org/D20677 Reviewers: EricWF, mclow.lists, bcraig llvm-svn: 271267
2016-05-31 04:01:32 -08:00
# Exceptions
if (LIBCXXABI_ENABLE_EXCEPTIONS)
# Catches C++ exceptions only and tells the compiler to assume that extern C
# functions never throw a C++ exception.
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
add_compile_flags_if_supported(-EHsc)
# Do we really need to be run through the C compiler ?
add_c_compile_flags_if_supported(-funwind-tables)
[libcxxabi] Introduce a -fno-exceptions libc++abi libary variant Currently there is only support for a -fno-exceptions libc++ build. This is problematic for functions such as std::terminate() which are defined in libc++abi and using any of those functions throws away most of the benefits of using -fno-exceptions (code-size). This patch introduces a -fno-exceptions libc++abi build to address this issue. This new variant of libc++abi cannot be linked against any with-exceptions code as some symbols necessary for handling exceptions are missing in this library. Differential revision: http://reviews.llvm.org/D20677 Reviewers: EricWF, mclow.lists, bcraig llvm-svn: 271267
2016-05-31 04:01:32 -08:00
else()
[libcxxabi] Rework CMakeLists.txt into modules Refactor cmake to remove dependence on LLVM's cmake modules. This improves handling of cmake checks when cross compiling and brings libcxxabi in line with libcxx and other project modules. Differential revision: https://reviews.llvm.org/D33635 llvm-svn: 304374
2017-05-31 16:09:20 -08:00
add_compile_flags_if_supported(-fno-exceptions)
add_compile_flags_if_supported(-EHs-)
add_compile_flags_if_supported(-EHa-)
[libcxxabi] Introduce a -fno-exceptions libc++abi libary variant Currently there is only support for a -fno-exceptions libc++ build. This is problematic for functions such as std::terminate() which are defined in libc++abi and using any of those functions throws away most of the benefits of using -fno-exceptions (code-size). This patch introduces a -fno-exceptions libc++abi build to address this issue. This new variant of libc++abi cannot be linked against any with-exceptions code as some symbols necessary for handling exceptions are missing in this library. Differential revision: http://reviews.llvm.org/D20677 Reviewers: EricWF, mclow.lists, bcraig llvm-svn: 271267
2016-05-31 04:01:32 -08:00
endif()
Add -funwind-tables to CMAKE_C_FLAGS. Without -funwind-tables, the compiler won't generate the unwinding table for these C functions. However, the functions in libunwind, such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace. llvm-svn: 226823
2015-01-22 04:39:08 -09:00
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
# Assert
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
if (LIBCXXABI_ENABLE_ASSERTIONS)
# MSVC doesn't like _DEBUG on release builds. See PR 4379.
if (NOT MSVC)
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
list(APPEND LIBCXXABI_COMPILE_FLAGS -D_DEBUG)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
endif()
# On Release builds cmake automatically defines NDEBUG, so we
# explicitly undefine it:
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
list(APPEND LIBCXXABI_COMPILE_FLAGS -UNDEBUG)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
endif()
else()
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE")
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
list(APPEND LIBCXXABI_COMPILE_FLAGS -DNDEBUG)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
endif()
endif()
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
# Threading
[libcxxabi] Refactor building and testing libc++abi without threads Summary: This patch adds CMake support for building and testing libc++abi without threads. 1. Add `LIBCXXABI_ENABLE_THREADS` option to CMake. 2. Propagate `LIBCXXABI_ENABLE_THREADS` to lit via lit.site.cfg.in 3. Configure tests for `LIBCXXABI_ENABLE_THREADS=OFF Currently the test suite does not work when libc++abi is built without threads because that information does not propagate to the test suite. Reviewers: danalbert, mclow.lists, jroelofs Reviewed By: jroelofs Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6393 llvm-svn: 222702
2014-11-24 13:42:03 -09:00
if (NOT LIBCXXABI_ENABLE_THREADS)
Allow explicit pthread opt-in When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi, along with llvm/projects/libcxx), libcxx's config_site.in doesn't get created in a timely manner. This means that any configuration that is normally set in libcxx's config_site.in needs to be duplicated in libcxxabi to successfully build libcxxabi. This patch does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. http://reviews.llvm.org/D20574 llvm-svn: 270732
2016-05-25 09:37:38 -08:00
if (LIBCXXABI_HAS_PTHREAD_API)
message(FATAL_ERROR "LIBCXXABI_HAS_PTHREAD_API can only"
" be set to ON when LIBCXXABI_ENABLE_THREADS"
" is also set to ON.")
endif()
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection. This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++. Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++. Differential revision: https://reviews.llvm.org/D98021
2021-03-05 05:30:13 -09:00
if (LIBCXXABI_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "LIBCXXABI_HAS_WIN32_THREAD_API can only"
" be set to ON when LIBCXXABI_ENABLE_THREADS"
" is also set to ON.")
endif()
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
message(FATAL_ERROR "LIBCXXABI_HAS_EXTERNAL_THREAD_API can only"
" be set to ON when LIBCXXABI_ENABLE_THREADS"
" is also set to ON.")
endif()
[libcxxabi] cleanup the use of LIBCXXABI_HAS_NO_THREADS macro (NFC) Align the naming / use of the macro LIBCXXABI_HAS_NO_THREADS to follow what we have in libcxx. NFC. llvm-svn: 282062
2016-09-21 01:09:32 -08:00
add_definitions(-D_LIBCXXABI_HAS_NO_THREADS)
[libcxxabi] Refactor building and testing libc++abi without threads Summary: This patch adds CMake support for building and testing libc++abi without threads. 1. Add `LIBCXXABI_ENABLE_THREADS` option to CMake. 2. Propagate `LIBCXXABI_ENABLE_THREADS` to lit via lit.site.cfg.in 3. Configure tests for `LIBCXXABI_ENABLE_THREADS=OFF Currently the test suite does not work when libc++abi is built without threads because that information does not propagate to the test suite. Reviewers: danalbert, mclow.lists, jroelofs Reviewed By: jroelofs Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6393 llvm-svn: 222702
2014-11-24 13:42:03 -09:00
endif()
[libcxxabi] Cleanup and adapt for r291275. NFC. + Now that libcxxabi shares the same threading API as libcxx, a whole chunk of code in src/config.h is made redundant (I missed this earlier). + r291275 split off the externalized-thread-api libcxx configuration from the external-thread-library libcxx configuration. libcxxabi should follow the same approach. llvm-svn: 291440
2017-01-09 02:57:21 -09:00
if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
if (LIBCXXABI_HAS_PTHREAD_API)
message(FATAL_ERROR "The options LIBCXXABI_HAS_EXTERNAL_THREAD_API"
" and LIBCXXABI_HAS_PTHREAD_API cannot be both"
" set to ON at the same time.")
endif()
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection. This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++. Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++. Differential revision: https://reviews.llvm.org/D98021
2021-03-05 05:30:13 -09:00
if (LIBCXXABI_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "The options LIBCXXABI_HAS_EXTERNAL_THREAD_API"
" and LIBCXXABI_HAS_WIN32_THREAD_API cannot be both"
" set to ON at the same time.")
endif()
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
endif()
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection. This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++. Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++. Differential revision: https://reviews.llvm.org/D98021
2021-03-05 05:30:13 -09:00
if (LIBCXXABI_HAS_PTHREAD_API)
if (LIBCXXABI_HAS_WIN32_THREAD_API)
message(FATAL_ERROR "The options LIBCXXABI_HAS_PTHREAD_API"
"and LIBCXXABI_HAS_WIN32_THREAD_API cannot be both"
"set to ON at the same time.")
endif()
endif()
libcxxabi: Suppress LLVM_ENABLE_MODULES Differential Revision: https://reviews.llvm.org/D35542 llvm-svn: 309551
2017-07-31 01:35:08 -08:00
if (LLVM_ENABLE_MODULES)
# Ignore that the rest of the modules flags are now unused.
add_compile_flags_if_supported(-Wno-unused-command-line-argument)
add_compile_flags(-fno-modules)
endif()
Fix CMake configuration errors on OS X llvm-svn: 296954
2017-03-03 17:15:37 -09:00
set(LIBCXXABI_HAS_UNDEFINED_SYMBOLS OFF)
[libc++] Remove internal "build-with-external-thread-library" configuration Our threading support layer is currently a huge mess. There are too many configurations with too many confusing names, and none of them are tested in the usual CI. Here's a list of names related to these configurations: LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL This patch cleans this up by removing the ability to build libc++ with an "external" threading library for testing purposes, removing 4 out of 6 "names" above. That setting was meant to be used by libc++ developers, but we don't use it in-tree and it's not part of our CI. I know the ability to use an external threading API is used by some folks out-of-tree, and this patch doesn't change that. This only changes the way they will have to test their external threading support. After this patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON` when building the library, and to provide their usual `<__external_threading>` header when they are testing the library. This can be done easily now that we support custom lit configuration files in test suites. The motivation for this patch is that our threading support layer is basically unmaintainable -- anything beyond adding a new "backend" in the slot designed for it requires incredible attention. The complexity added by this setting just doesn't pull its weigh considering the available alternatives. Concretely, this will also allow future patches to clean up `<__threading_support>` significantly. Differential Revision: https://reviews.llvm.org/D154466
2023-07-04 14:44:00 -08:00
if ((NOT LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS) OR MINGW)
Fix CMake configuration errors on OS X llvm-svn: 296954
2017-03-03 17:15:37 -09:00
set(LIBCXXABI_HAS_UNDEFINED_SYMBOLS ON)
endif()
[libc++abi] Add option to enable definitions for the new/delete overloads. Summary: Currently both libc++ and libc++abi provide definitions for operator new/delete. However I believe this is incorrect and that one or the other should offer them. This patch adds the CMake option `-DLIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS` which defaults to `OFF` unless otherwise specified. This means that by default only libc++ provides the new/delete definitions. Reviewers: mclow.lists, mehdi_amini, dexonsmith, beanz, jroelofs, danalbert, smeenai, rmaprath, mgorny Reviewed By: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30517 llvm-svn: 296801
2017-03-02 10:34:35 -09:00
if (LIBCXXABI_HAS_UNDEFINED_SYMBOLS)
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
# Need to allow unresolved symbols if this is to work with shared library builds
if (APPLE)
Fix CMake configuration errors on OS X llvm-svn: 296954
2017-03-03 17:15:37 -09:00
list(APPEND LIBCXXABI_LINK_FLAGS "-undefined dynamic_lookup")
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
else()
# Relax this restriction from HandleLLVMOptions
string(REPLACE "-Wl,-z,defs" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
endif()
endif()
Allow explicit pthread opt-in When building libcxxabi in tree (i.e. in llvm/projects/libcxxabi, along with llvm/projects/libcxx), libcxx's config_site.in doesn't get created in a timely manner. This means that any configuration that is normally set in libcxx's config_site.in needs to be duplicated in libcxxabi to successfully build libcxxabi. This patch does exactly that for the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. http://reviews.llvm.org/D20574 llvm-svn: 270732
2016-05-25 09:37:38 -08:00
if (LIBCXXABI_HAS_PTHREAD_API)
add_definitions(-D_LIBCPP_HAS_THREAD_API_PTHREAD)
endif()
[libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection. This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++. Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++. Differential revision: https://reviews.llvm.org/D98021
2021-03-05 05:30:13 -09:00
if (LIBCXXABI_HAS_WIN32_THREAD_API)
add_definitions(-D_LIBCPP_HAS_THREAD_API_WIN32)
endif()
[libcxxabi] Introduce an externally threaded libc++abi variant. r281179 Introduced an externally threaded variant of the libc++ library. This patch adds support for a similar library variant for libc++abi. Differential revision: https://reviews.llvm.org/D27575 Reviewers: EricWF llvm-svn: 290888
2017-01-03 03:58:34 -09:00
if (LIBCXXABI_HAS_EXTERNAL_THREAD_API)
[libcxxabi] Cleanup and adapt for r291275. NFC. + Now that libcxxabi shares the same threading API as libcxx, a whole chunk of code in src/config.h is made redundant (I missed this earlier). + r291275 split off the externalized-thread-api libcxx configuration from the external-thread-library libcxx configuration. libcxxabi should follow the same approach. llvm-svn: 291440
2017-01-09 02:57:21 -09:00
add_definitions(-D_LIBCPP_HAS_THREAD_API_EXTERNAL)
endif()
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
if (MSVC)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
endif()
[libc++abi] Add a silent terminate handler to libcxxabi. The current std::terminate_handler pulls in some string code, some I/O code, and more. Since it is automatically setup as the default, this means that any trivial binary linking against libcxxabi will get this extra bloat. This patch allows disabling it as a build-time option, if you want to avoid the extra bloat. Patch by Tom Rybka! Reviewers: EricWF Subscribers: danalbert, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28497 llvm-svn: 291946
2017-01-13 10:22:26 -09:00
if (LIBCXXABI_SILENT_TERMINATE)
[libcxxabi] Clean up macro usage. Convention in libcxxabi is to use !defined(FOO) not !FOO. Differential Revision: https://reviews.llvm.org/D30459 llvm-svn: 296612
2017-03-01 02:42:01 -09:00
add_definitions(-DLIBCXXABI_SILENT_TERMINATE)
endif()
[libc++abi] Add an option to avoid demangling in terminate. We've been using this patch in Android so we can avoid including the demangler in libc++.so. It comes with a rather large cost in RSS and isn't commonly needed. Reviewed By: #libc_abi, compnerd Differential Revision: https://reviews.llvm.org/D88189
2021-01-21 12:27:14 -09:00
if (LIBCXXABI_NON_DEMANGLING_TERMINATE)
add_definitions(-DLIBCXXABI_NON_DEMANGLING_TERMINATE)
endif()
[libcxxabi] Clean up macro usage. Convention in libcxxabi is to use !defined(FOO) not !FOO. Differential Revision: https://reviews.llvm.org/D30459 llvm-svn: 296612
2017-03-01 02:42:01 -09:00
if (LIBCXXABI_BAREMETAL)
add_definitions(-DLIBCXXABI_BAREMETAL)
[libc++abi] Add a silent terminate handler to libcxxabi. The current std::terminate_handler pulls in some string code, some I/O code, and more. Since it is automatically setup as the default, this means that any trivial binary linking against libcxxabi will get this extra bloat. This patch allows disabling it as a build-time option, if you want to avoid the extra bloat. Patch by Tom Rybka! Reviewers: EricWF Subscribers: danalbert, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28497 llvm-svn: 291946
2017-01-13 10:22:26 -09:00
endif()
[runtimes] [CMake] Unify variable names Avoid repeating CMake checks across runtimes by unifying names of variables used for results to leverage CMake caching. Differential Revision: https://reviews.llvm.org/D110005
2022-03-10 00:47:09 -09:00
if (C_SUPPORTS_COMMENT_LIB_PRAGMA)
[libcxx{,abi}] Emit deplibs only when detected by CMake This is a followup to 35bc5276ca3. It fixes the dependent libs usage in libcxx and libcxxabi to link pthread and rt libraries only if CMake detects them, rather than based on explicit platform blacklist. Differential Revision: https://reviews.llvm.org/D70888
2019-12-02 01:49:20 -09:00
if (LIBCXXABI_HAS_PTHREAD_LIB)
add_definitions(-D_LIBCXXABI_LINK_PTHREAD_LIB)
endif()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-29 20:40:21 -08:00
endif()
[libcxxabi] Refactor CMakeLists.txt's handling of compile and link flags to suppress warnings. Summary: This patch mirrors the recent change to libc++ found here http://reviews.llvm.org/D6277. This fixes PR20395 (http://llvm.org/bugs/show_bug.cgi?id=20395). Reviewers: jroelofs, mclow.lists, danalbert Reviewed By: danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6286 llvm-svn: 222252
2014-11-18 11:37:53 -09:00
string(REPLACE ";" " " LIBCXXABI_CXX_FLAGS "${LIBCXXABI_CXX_FLAGS}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${LIBCXXABI_CXX_FLAGS}")
Add -funwind-tables to CMAKE_C_FLAGS. Without -funwind-tables, the compiler won't generate the unwinding table for these C functions. However, the functions in libunwind, such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace. llvm-svn: 226823
2015-01-22 04:39:08 -09:00
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${LIBCXXABI_C_FLAGS}")
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 08:44:44 -09:00
# On AIX, avoid picking up VMX extensions(i.e. vec_malloc) which would change
# the default alignment of the allocators here.
[NFC][CMake] quote ${CMAKE_SYSTEM_NAME} consistently (#154537) A CMake change included in CMake 4.0 makes `AIX` into a variable (similar to `APPLE`, etc.) https://gitlab.kitware.com/cmake/cmake/-/commit/ff03db6657c38c8cf992877ea66174c33d0bcb0b However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to `AIX` and `if` auto-expands variable names in CMake. That means you get a double expansion if you write: `if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")` which becomes: `if (AIX MATCHES "AIX")` which is as if you wrote: `if (ON MATCHES "AIX")` You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}", due to policy [CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054) which is on by default in 4.0+. Most of the LLVM CMake already does this, but this PR fixes the remaining cases where we do not.
2025-08-20 08:45:41 -08:00
if (UNIX AND "${CMAKE_SYSTEM_NAME}" MATCHES "AIX")
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 08:44:44 -09:00
add_definitions("-D_XOPEN_SOURCE=700")
endif()
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
#===============================================================================
# Setup Source Code
#===============================================================================
Fix "TODO" and provide the configure-time options to find libunwind. This is done the same way as we're looking for libc++ llvm-svn: 236874
2015-05-08 08:10:11 -08:00
set(LIBCXXABI_LIBUNWIND_INCLUDES "${LIBCXXABI_LIBUNWIND_INCLUDES}" CACHE PATH
"Specify path to libunwind includes." FORCE)
set(LIBCXXABI_LIBUNWIND_PATH "${LIBCXXABI_LIBUNWIND_PATH}" CACHE PATH
"Specify path to libunwind source." FORCE)
Fix syntax error in CMake created when a variable is not defined. llvm-svn: 236115
2015-04-29 07:53:03 -08:00
if (LIBCXXABI_USE_LLVM_UNWINDER OR LLVM_NATIVE_ARCH MATCHES ARM)
[gn] Support for building libcxxabi This change introduces support for building libcxxabi. The library build should be complete, but not all CMake options have been replicated in GN. We also don't support tests yet. We only support two stage build at the moment. Differential Revision: https://reviews.llvm.org/D60372 llvm-svn: 359805
2019-05-02 09:29:39 -08:00
find_path(LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL libunwind.h
Fix "TODO" and provide the configure-time options to find libunwind. This is done the same way as we're looking for libc++ llvm-svn: 236874
2015-05-08 08:10:11 -08:00
PATHS ${LIBCXXABI_LIBUNWIND_INCLUDES}
${LIBCXXABI_LIBUNWIND_PATH}/include
${CMAKE_BINARY_DIR}/${LIBCXXABI_LIBUNWIND_INCLUDES}
${LLVM_MAIN_SRC_DIR}/projects/libunwind/include
[CMake] Check runtimes subdir when looking for libcxx and libuwind The runtimes subdir is the new location for runtimes, we should include it when looking for libcxx and libunwind headers. Differential Revision: https://reviews.llvm.org/D26362 llvm-svn: 286614
2016-11-11 10:12:58 -09:00
${LLVM_MAIN_SRC_DIR}/runtimes/libunwind/include
[CMake] Support for monorepo layout Support finding libcxx and libunwind sources in monorepo style layout. Differential Revision: https://reviews.llvm.org/D45269 llvm-svn: 329208
2018-04-04 09:40:59 -08:00
${LLVM_MAIN_SRC_DIR}/../libunwind/include
LIBCXXABI_LIBUNWIND_INCLUDES is already set before calling find_path, and find_path will not update it. So cmake will throw error "include_directories given empty-string as include directory". Use other variable name for the include path and do not find the default libunwind.h in the system path. http://reviews.llvm.org/D9641 Patch by Jingyi Wei! llvm-svn: 236936
2015-05-09 13:03:01 -08:00
NO_DEFAULT_PATH
[cmake] [libcxxabi] Fix find_path() problems when cross compiling When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY globally which means find_path() always prepends CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH to all paths used in the search. However, these find_path() invocations are looking for paths in the libcxx and libunwind projects on the host system, not the target system, which can be done by passing NO_CMAKE_FIND_ROOT_PATH. Differential Revision: https://reviews.llvm.org/D41623 llvm-svn: 323145
2018-01-22 10:41:05 -09:00
NO_CMAKE_FIND_ROOT_PATH
Fix "TODO" and provide the configure-time options to find libunwind. This is done the same way as we're looking for libc++ llvm-svn: 236874
2015-05-08 08:10:11 -08:00
)
Fix exception address alignment test for EHABI This test fails on ARM bare-metal targets because it assumes the Itanium ABI, whereas EHABI requires the exception address to be 8-byte aligned. I was a bit puzzled at first because this should've failed on the public arm-linux builder too. I think the reason it passes there is because we don't include libunwind headers in the include path when running the libcxxabi tests, so the system unwind.h gets picked up. Reviewers: rengolin, EricWF Differential revision: https://reviews.llvm.org/D31178 llvm-svn: 299435
2017-04-04 06:03:54 -08:00
if (LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL-NOTFOUND")
set(LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL "")
endif()
[SystemZ][z/OS] Make LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL available for external unwind library. On z/OS, we need to pass the location of unwind interface header when building cxxabi. The cmake macro `LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL` is available for this purpose but it is only used with conjunction with `LIBCXXABI_USE_LLVM_UNWINDER`. For the external unwind library we need to use LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL unconditionally whenever it is set. Reviewed By: #libc_abi, muiez, phosek, SeanP Differential Revision: https://reviews.llvm.org/D147460
2023-04-21 08:29:36 -08:00
endif()
Fix exception address alignment test for EHABI This test fails on ARM bare-metal targets because it assumes the Itanium ABI, whereas EHABI requires the exception address to be 8-byte aligned. I was a bit puzzled at first because this should've failed on the public arm-linux builder too. I think the reason it passes there is because we don't include libunwind headers in the include path when running the libcxxabi tests, so the system unwind.h gets picked up. Reviewers: rengolin, EricWF Differential revision: https://reviews.llvm.org/D31178 llvm-svn: 299435
2017-04-04 06:03:54 -08:00
[SystemZ][z/OS] Make LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL available for external unwind library. On z/OS, we need to pass the location of unwind interface header when building cxxabi. The cmake macro `LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL` is available for this purpose but it is only used with conjunction with `LIBCXXABI_USE_LLVM_UNWINDER`. For the external unwind library we need to use LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL unconditionally whenever it is set. Reviewed By: #libc_abi, muiez, phosek, SeanP Differential Revision: https://reviews.llvm.org/D147460
2023-04-21 08:29:36 -08:00
if (NOT "${LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL}" STREQUAL "")
include_directories("${LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL}")
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23092 llvm-svn: 278030
2016-08-08 09:59:02 -08:00
endif()
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
[runtimes][CMake] Simplify the propagation of test dependencies (#93558) Instead of using FOO_TEST_DEPS global variables that don't get updated properly from subdirectories, use targets to propagate the dependencies across directories.
2024-05-28 17:31:01 -08:00
add_custom_target(cxxabi-test-depends
COMMENT "Build dependencies required to run the libc++abi test suite.")
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
# Add source code. This also contains all of the logic for deciding linker flags
# soname, etc...
[libc++abi] Install the libc++abi headers from libc++abi libc++abi should be responsible for installing its own headers, it doesn't make sense for libc++ to be responsible for it. Differential Revision: https://reviews.llvm.org/D101458
2022-02-17 07:19:45 -09:00
add_subdirectory(include)
Add a cmake build system. Will add support for tests with lit in a later patch. This does not yet support building the unwinder in src/Unwind. llvm-svn: 212286
2014-07-03 11:35:48 -08:00
add_subdirectory(src)
Add lit configs for libcxxabi tests. This makes running libcxxabi tests on Linux _much_ easier. Adds a check-libcxxabi target to cmake. Also defaults to building a dynamic libc++abi. This is so that the default options still test the libc++abi that is being built. There are two problems with testing a static libc++abi. In the case of a standalone build, the tests will link the system's libc++, which might not have been built against our libc++abi. In the case of an in tree build, libc++ will prefer a dynamic libc++abi from the system over a static libc++abi from the output directory. llvm-svn: 212672
2014-07-09 18:20:11 -08:00
[cmake] [libcxxabi] Don't print warning when tests are disabled. Summary: Don't print, possibly erroneous, warning if LIBCXXABI_INCLUDE_TESTS is false. This patch fixes a problem introduced in r291367. Differential Revision: https://reviews.llvm.org/D42229 llvm-svn: 322870
2018-01-18 09:29:36 -09:00
if (LIBCXXABI_INCLUDE_TESTS)
[libcxxabi,libunwind] support running tests in standalone mode Remove check for standalone and shared library mode in libcxxabi to allow including tests in said mode. This check prevented running the tests in standalone mode with static libraries, which is the case for baremetal targets. Fix check-unwind target trying to use a non-existent llvm-lit executable in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to libunwind in order to make the tests work in standalone mode. Reviewed By: ldionne, #libc_abi, #libc Differential Revision: https://reviews.llvm.org/D86540
2020-08-24 01:01:05 -08:00
add_subdirectory(test)
add_subdirectory(fuzz)
Add lit configs for libcxxabi tests. This makes running libcxxabi tests on Linux _much_ easier. Adds a check-libcxxabi target to cmake. Also defaults to building a dynamic libc++abi. This is so that the default options still test the libc++abi that is being built. There are two problems with testing a static libc++abi. In the case of a standalone build, the tests will link the system's libc++, which might not have been built against our libc++abi. In the case of an in tree build, libc++ will prefer a dynamic libc++abi from the system over a static libc++abi from the output directory. llvm-svn: 212672
2014-07-09 18:20:11 -08:00
endif()
Reference in a new issue Copy permalink