maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxxabi/CMakeLists.txt

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

560 lines
22 KiB
CMake
Raw 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-06-01 08:09:20 +08:00
# See www/CMake.html for instructions on how to build libcxxabi with CMake.
Enforce that libc++ and libc++abi are built in a monorepo layout We will soon start removing technical debt and sharing code between the two directories, so this first step is meant to discover potential places where the libraries are built outside of a monorepo layout. I imagine this could happen as a remnant of the pre-monorepo setup. This was discussed on the libcxx-dev mailing list and we got overall consensus on the direction. All consumers of libc++ and libc++abi should already be doing so through the monorepo, however it is possible that we catch some stragglers with this patch, in which case it may need to be reverted temporarily. Differential Revision: https://reviews.llvm.org/D76102
2020-03-13 06:01:20 +08:00
if (NOT IS_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/../libcxx")
message(FATAL_ERROR "libc++abi now requires being built in a monorepo layout with libcxx available")
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-04 03:35:48 +08:00
#===============================================================================
# Setup Project
#===============================================================================
[CMake] Bump CMake minimum version to 3.13.4 This upgrade should be friction-less because we've already been ensuring that CMake >= 3.13.4 is used. This is part of the effort discussed on llvm-dev here: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140578.html Differential Revision: https://reviews.llvm.org/D78648
2020-04-22 23:15:05 +08:00
cmake_minimum_required(VERSION 3.13.4)
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-04 03: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
2022-01-01 15:03:31 +08: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-08 04: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
2022-01-01 15:03:31 +08: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-08 04:10:41 +08:00
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/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
2022-01-01 15:03:31 +08: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-08 04: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-25 16:50:03 +08: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 17: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.")
[compiler-rt] Build custom libcxx with libcxxabi This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
2019-02-17 20:16:20 +08:00
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBCXXABI_STANDALONE_BUILD)
[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-06-01 08:09:20 +08:00
project(libcxxabi CXX C)
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-04 03:35:48 +08:00
set(PACKAGE_NAME libcxxabi)
[libc++abi] Bump PACKAGE_VERSION
2020-01-31 04:18:24 +08:00
set(PACKAGE_VERSION 11.0.0git)
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-04 03:35:48 +08:00
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
Update to new lists.llvm.org llvm-svn: 244004
2015-08-05 12:01:26 +08:00
set(PACKAGE_BUGREPORT "llvm-bugs@lists.llvm.org")
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-04 03:35:48 +08:00
[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-19 14:45:07 +08:00
set(LIBCXXABI_STANDALONE_BUILD TRUE)
[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 17:01:05 +08:00
# In a standalone build, we don't have llvm to automatically generate the
# llvm-lit script for us. So we need to provide an explicit directory that
# the configurator should write the script into.
set(LLVM_LIT_OUTPUT_DIR "${LIBCXXABI_BINARY_DIR}/bin")
[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-19 14:45:07 +08:00
endif()
[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 17:01:05 +08:00
[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-19 14:45:07 +08:00
# Must go below project(..)
include(GNUInstallDirs)
if (LIBCXXABI_STANDALONE_BUILD)
[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-06-01 08:09:20 +08:00
# Find the LLVM sources and simulate LLVM CMake options.
include(HandleOutOfTreeLLVM)
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-04 03:35:48 +08:00
[libc++abi] Make sure we can run the tests in Standalone mode The tests would previously fail if the `python` executable wasn't found, because we were missing the mandatory find_package.
2020-10-27 02:25:49 +08:00
find_package(Python3 COMPONENTS Interpreter)
if(NOT Python3_Interpreter_FOUND)
message(WARNING "Python3 not found, using python2 as a fallback")
find_package(Python2 COMPONENTS Interpreter REQUIRED)
if(Python2_VERSION VERSION_LESS 2.7)
message(SEND_ERROR "Python 2.7 or newer is required")
endif()
# Treat python2 as python3
add_executable(Python3::Interpreter IMPORTED)
set_target_properties(Python3::Interpreter PROPERTIES
IMPORTED_LOCATION ${Python2_EXECUTABLE})
set(Python3_EXECUTABLE ${Python2_EXECUTABLE})
endif()
endif()
[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-06-01 08: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."
)
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-04 03: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-06-01 08: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-08 04: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-04 03: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-13 03: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-04 03:35:48 +08:00
option(LIBCXXABI_ENABLE_ASSERTIONS "Enable assertions independent of build mode." ON)
option(LIBCXXABI_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
option(LIBCXXABI_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
libc++abi: try harder to force the LLVM unwinder on ARM Attempting to default the option to ON for ARM doesnt seem to work. Force the check lower and perform the check at the two sites that matter: the CPPFLAGS definition and the header search path setup. llvm-svn: 235964
2015-04-28 10:09:53 +08:00
option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
[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-09 10:19:30 +08: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-15 08: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-25 06:42:03 +08: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-26 01: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 22:30:13 +08: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 20:58:34 +08: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)
[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 19:57:21 +08:00
option(LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
"Build libc++abi with an externalized threading library.
This option may only be set to ON when LIBCXXABI_ENABLE_THREADS=ON" OFF)
[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-23 04: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-03 05:55:17 +08: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-03 03:34:35 +08: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 21: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-24 05:34:09 +08: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-02 01:57:30 +08: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-24 05:34:09 +08:00
endif()
[libcxxabi] Add flag to conditionally enable tests Differential Revision: https://reviews.llvm.org/D28449 llvm-svn: 291367
2017-01-08 06:14:04 +08:00
option(LIBCXXABI_INCLUDE_TESTS "Generate build targets for the libc++abi unit tests." ${LLVM_INCLUDE_TESTS})
Set a default value for LIBCXXABI_LIBDIR_SUFFIX, fixes installing into lib64 after r304374 llvm-svn: 305278
2017-06-13 16:16:44 +08:00
set(LIBCXXABI_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
"Define suffix of library directory name (32/64)")
[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-18 07:25:09 +08:00
option(LIBCXXABI_INSTALL_LIBRARY "Install the libc++abi library." ON)
[runtimes] Properly handle the sysroot/triple/gcc-toolchain In 395271a, I simplified how we handled the target triple for the runtimes. However, in doing so, we stopped considering the default in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE (which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified. This commit fixes that problem and also refactors the code so that it's easy to see what the default value is. The fact that nobody seems to have been broken by this makes me think that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the triple -- but it should still work. Differential Revision: https://reviews.llvm.org/D111672
2021-10-13 03:59:08 +08:00
if(CMAKE_CXX_COMPILER_TARGET)
set(LIBCXXABI_DEFAULT_TARGET_TRIPLE "${CMAKE_CXX_COMPILER_TARGET}")
else()
set(LIBCXXABI_DEFAULT_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}")
endif()
set(LIBCXXABI_TARGET_TRIPLE "${LIBCXXABI_DEFAULT_TARGET_TRIPLE}" CACHE STRING "Target triple for cross compiling.")
set(LIBCXXABI_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}" CACHE PATH "GCC toolchain for cross compiling.")
set(LIBCXXABI_SYSROOT "${CMAKE_SYSROOT}" CACHE PATH "Sysroot for cross compiling.")
Missed part of D16545 (static lib testing) http://reviews.llvm.org/D16545 llvm-svn: 271388
2016-06-01 20: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-08 03: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-10 10:20:11 +08:00
# Default to building a shared library 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.
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 23:59:09 +08: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-26 07: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-24 15:06:17 +08:00
cmake_dependent_option(LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_STATIC_LIBRARY
"Statically link the LLVM unwinder to static library" ON
"LIBCXXABI_ENABLE_STATIC_UNWINDER;LIBCXXABI_ENABLE_STATIC" OFF)
cmake_dependent_option(LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY
"Statically link the LLVM unwinder to shared library" ON
"LIBCXXABI_ENABLE_STATIC_UNWINDER;LIBCXXABI_ENABLE_SHARED" 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 19:42:01 +08: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-22 05:27:14 +08: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 19:42:01 +08: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 23:59:09 +08: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-10 10:20:11 +08:00
[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-11 03:21:41 +08:00
# TODO: This is a workaround for the fact that Standalone builds can't use
# targets from the other runtimes (so the cxx-headers target doesn't exist).
set(LIBCXXABI_LIBCXX_INCLUDES "" CACHE PATH
[runtimes] Revert the libc++ __config_site change This is a massive revert of the following commits (from most revent to oldest): 2b9b7b5775a1d8fcd7aa5abaa8fc0bc303434f1a. 529ac33197f6408952ae995075ac5e2dc5287e81 28270234f1478047e35879f4ba8838b47edfcc14 69c2087283cf7b17ca75f69daebf4ffc158b754a b5aa67446e01bd277727b05710a42e69ac41e74b 5d796645d6c8cadeb003715c33e231a8ba05b6de After checking-in the __config_site change, a lot of things started breaking due to widespread reliance on various aspects of libc++'s build, notably the fact that we can include the headers from the source tree, but also reliance on various "internal" CMake variables used by the runtimes build and compiler-rt. These were unintended consequences of the change, and after two days, we still haven't restored all the bots to being green. Instead, now that I understand what specific areas this will blow up in, I should be able to chop up the patch into smaller ones that are easier to digest. See https://reviews.llvm.org/D89041 for more details on this adventure.
2020-10-23 21:32:50 +08:00
"Specify path to libc++ includes.")
[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-11 03:21:41 +08:00
if (LIBCXXABI_STANDALONE_BUILD)
if (NOT IS_DIRECTORY ${LIBCXXABI_LIBCXX_INCLUDES})
message(FATAL_ERROR
"LIBCXXABI_LIBCXX_INCLUDES=${LIBCXXABI_LIBCXX_INCLUDES} is not a valid directory. "
"Please provide the path to where the libc++ headers have been installed.")
endif()
add_library(cxx-headers INTERFACE)
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "MSVC" OR "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
target_compile_options(cxx-headers INTERFACE /I "${LIBCXXABI_LIBCXX_INCLUDES}")
else()
target_compile_options(cxx-headers INTERFACE -I "${LIBCXXABI_LIBCXX_INCLUDES}")
endif()
endif()
[libc++abi] Fix the standalone build after the __config_site change In 5d796645, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable, which broke users of the Standalone build. This patch reinstates that variable, however it must point to the *installed* path of the libc++ headers, not the libc++ headers in the source tree (which has always been the case, but wasn't enforced before). If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source tree, the `__config_site` header will fail to be found.
2020-10-23 07:11:33 +08:00
[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-24 11:18:29 +08:00
option(LIBCXXABI_HERMETIC_STATIC_LIBRARY
"Do not export any symbols from the static library." OFF)
[libc++abi] Allow specifying custom Lit config files This is the libc++abi counterpart of 0c66af970c80.
2020-06-25 23:46:00 +08:00
set(LIBCXXABI_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/lit.site.cfg.in" 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-30 03: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-13 05: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-30 03: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-13 05: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-30 03:26:05 +08:00
endif()
[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 23: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 23: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-04 03: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}
)
[libcxx][libcxxabi][libunwind][cmake] Use `GNUInstallDirs` to support custom installation dirs I am breaking apart D99484 so the cause of build failures is easier to understand. Differential Revision: https://reviews.llvm.org/D117417
2022-01-16 14:00:29 +08:00
set(LIBCXXABI_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
[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-11 11:03:21 +08:00
"Path where built libc++abi runtime libraries should be installed.")
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-28 11:11:52 +08:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
[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-11 03:21:41 +08:00
set(LIBCXXABI_HEADER_DIR ${LLVM_BINARY_DIR})
[libcxx] Stop using use c++ subdirectory for libc++ library The new layout more closely matches the layout used by other compilers. This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled. Differential Revision: https://reviews.llvm.org/D100869
2021-04-17 12:33:18 +08:00
set(LIBCXXABI_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
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-29 06:36:47 +08:00
set(LIBCXXABI_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
"Path where built libc++abi libraries should be installed.")
[runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
2019-05-23 05:08:33 +08:00
if(LIBCXX_LIBDIR_SUBDIR)
string(APPEND LIBCXXABI_LIBRARY_DIR /${LIBCXXABI_LIBDIR_SUBDIR})
string(APPEND LIBCXXABI_INSTALL_LIBRARY_DIR /${LIBCXXABI_LIBDIR_SUBDIR})
endif()
[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-04 14: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-11 11:03:21 +08: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})
set(LIBCXXABI_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXXABI_LIBDIR_SUFFIX})
endif()
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-29 06:36:47 +08:00
set(LIBCXXABI_INSTALL_LIBRARY_DIR lib${LIBCXXABI_LIBDIR_SUFFIX} CACHE PATH
"Path where built libc++abi libraries 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-04 14: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 20:22:04 +08: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 21: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-06-01 08: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 21:30:38 +08:00
Missed part of D16545 (static lib testing) http://reviews.llvm.org/D16545 llvm-svn: 271388
2016-06-01 20:50:30 +08:00
# By default, for non-standalone builds, libcxx and libcxxabi share a library
# directory.
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 17:28:39 +08: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-09 01: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-02 10: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-06-01 08: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-02 10: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 21:39:08 +08: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-19 04:37:53 +08: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-06-01 08:09:20 +08:00
set(LIBCXXABI_LIBRARIES "")
# 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-19 04:37:53 +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-02 10:18:31 +08:00
# Configure target flags
[SystemZ][z/OS] ASCII/EBCDIC support with no coexistence The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch. Differential Revision: https://reviews.llvm.org/D114813
2022-01-15 00:35:53 +08:00
if(ZOS)
add_target_flags_if_supported("-fzos-le-char-mode=ebcdic")
endif()
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
if(LIBCXXABI_TARGET_TRIPLE)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--target=${LIBCXXABI_TARGET_TRIPLE}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
endif()
[runtimes] Properly handle the sysroot/triple/gcc-toolchain In 395271a, I simplified how we handled the target triple for the runtimes. However, in doing so, we stopped considering the default in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE (which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified. This commit fixes that problem and also refactors the code so that it's easy to see what the default value is. The fact that nobody seems to have been broken by this makes me think that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the triple -- but it should still work. Differential Revision: https://reviews.llvm.org/D111672
2021-10-13 03:59:08 +08:00
if(LIBCXXABI_GCC_TOOLCHAIN)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--gcc-toolchain=${LIBCXXABI_GCC_TOOLCHAIN}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +08:00
endif()
if(LIBCXXABI_SYSROOT)
[runtimes] Don't try passing --target flags to GCC When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried passing the --target=<...> flag to the compiler. However, not all compilers support that flag (e.g. GCC, which is not a cross-compiler). As a result, setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to pass --target=<host-triple> to GCC, which breaks everything because the flag isn't even supported. This commit only adds `--target=<...>` & friends to the flags if it is supported by the compiler. One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...> and have it be ignored. That's correct, and one possibility would be to assert that the requested triple is the same as the host triple when we know the compiler is unable to cross-compile. However, note that this is a pre-existing issue (setting the TARGET_TRIPLE variable never had an influence on the flags passed to the compiler), and also fixing that is starting to look like reimplementing a lot of CMake logic that is already handled with CMAKE_CXX_COMPILER_TARGET. Differential Revision: https://reviews.llvm.org/D106082
2021-07-16 01:02:43 +08:00
add_target_flags_if_supported("--sysroot=${LIBCXXABI_SYSROOT}")
[CMake] Support CMake variables for setting target, sysroot and toolchain CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
2019-02-05 04:02:26 +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-02 10: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-19 04:37:53 +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-04 03:35:48 +08:00
if (LIBCXXABI_HAS_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-19 04:37:53 +08: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-08 06:51:25 +08: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-19 04:37:53 +08: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 22: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-19 04:37:53 +08: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-04 03:35:48 +08:00
endif()
[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-27 11: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-31 01: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++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-27 11:44:09 +08:00
# Disable DLL annotations on Windows for static builds.
if (WIN32 AND LIBCXXABI_ENABLE_STATIC AND NOT LIBCXXABI_ENABLE_SHARED)
[libcxx] [libcxxabi] Set flags for visibility when statically linking libcxxabi into libcxx for windows Previously, these had to be set manually when building each of the projects standalone, in order to get proper symbol visibility when combining the two libraries. Differential Revision: https://reviews.llvm.org/D90021
2020-10-23 15:54:02 +08:00
if (LIBCXX_ENABLE_SHARED AND LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
# Building libcxxabi statically, but intending for it to be statically
# linked into a shared libcxx; keep dllexport enabled within libcxxabi,
# as the symbols will need to be exported from libcxx.
else()
# Regular static build; disable dllexports.
add_definitions(-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
endif()
[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-27 11:44:09 +08:00
endif()
[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-06-01 08:09:20 +08:00
add_compile_flags_if_supported(-Werror=return-type)
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-04 03:35:48 +08:00
# Get warning 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-06-01 08:09:20 +08:00
add_compile_flags_if_supported(-W)
add_compile_flags_if_supported(-Wall)
add_compile_flags_if_supported(-Wchar-subscripts)
add_compile_flags_if_supported(-Wconversion)
add_compile_flags_if_supported(-Wmismatched-tags)
add_compile_flags_if_supported(-Wmissing-braces)
add_compile_flags_if_supported(-Wnewline-eof)
add_compile_flags_if_supported(-Wunused-function)
add_compile_flags_if_supported(-Wshadow)
add_compile_flags_if_supported(-Wshorten-64-to-32)
add_compile_flags_if_supported(-Wsign-compare)
add_compile_flags_if_supported(-Wsign-conversion)
add_compile_flags_if_supported(-Wstrict-aliasing=2)
add_compile_flags_if_supported(-Wstrict-overflow=4)
add_compile_flags_if_supported(-Wunused-parameter)
add_compile_flags_if_supported(-Wunused-variable)
add_compile_flags_if_supported(-Wwrite-strings)
add_compile_flags_if_supported(-Wundef)
Make cmake cxxflags match those in lib/buildit. llvm-svn: 212768
2014-07-11 06:23:03 +08:00
Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories." add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it. Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-23 08:44:52 +08:00
add_compile_flags_if_supported(-Wno-suggest-override)
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-04 03:35:48 +08:00
if (LIBCXXABI_ENABLE_WERROR)
[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-06-01 08:09:20 +08:00
add_compile_flags_if_supported(-Werror)
add_compile_flags_if_supported(-WX)
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-04 03:35:48 +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-06-01 08:09:20 +08:00
add_compile_flags_if_supported(-Wno-error)
add_compile_flags_if_supported(-WX-)
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-04 03:35:48 +08:00
endif()
if (LIBCXXABI_ENABLE_PEDANTIC)
[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-06-01 08:09:20 +08:00
add_compile_flags_if_supported(-pedantic)
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-04 03:35:48 +08:00
endif()
# 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-06-01 08: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-04 03: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 20: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-06-01 08: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 20: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-06-01 08: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 20: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 21:39:08 +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-04 03: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-19 04:37:53 +08: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-04 03: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-19 04:37:53 +08: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-04 03: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-19 04:37:53 +08: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-04 03: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 20:58:34 +08: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-25 06:42:03 +08: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-26 01: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 22:30:13 +08: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 20:58:34 +08: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 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 19:57:21 +08:00
if (LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY)
message(FATAL_ERROR "LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY 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 17: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-25 06:42:03 +08: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 19:57:21 +08: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 22:30:13 +08: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] 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 19:57:21 +08:00
if (LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY)
message(FATAL_ERROR "The options LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY"
" and LIBCXXABI_HAS_EXTERNAL_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 20:58:34 +08: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 22:30:13 +08: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 17: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-04 10:15:37 +08:00
set(LIBCXXABI_HAS_UNDEFINED_SYMBOLS OFF)
if ((NOT LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS)
Allow undefined symbols when linking libc++abi.dll on Windows llvm-svn: 302761
2017-05-11 11:49:48 +08:00
OR (LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY AND LIBCXXABI_ENABLE_SHARED)
OR MINGW)
Fix CMake configuration errors on OS X llvm-svn: 296954
2017-03-04 10:15:37 +08: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-03 03:34:35 +08: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 20:58:34 +08: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-04 10:15:37 +08: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 20:58:34 +08: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-26 01: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 22:30:13 +08: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 20:58:34 +08: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 19:57:21 +08:00
add_definitions(-D_LIBCPP_HAS_THREAD_API_EXTERNAL)
endif()
if (LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY)
add_definitions(-D_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
[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 20:58:34 +08:00
endif()
[libc++abi] Disable libc++ extern templates project-wide libc++abi can't depend on libc++, so disable extern templates in libc++ headers project-wide. This was previously done in cxa_demangle.cpp, but I consider it more appropriate to do at the cmake level (since none of libc++abi's source files can use libc++ extern templates). I also think the _LIBCPP_NO_EXCEPTIONS in cxa_demangle.cpp is suspicious, but I'm doing one thing at a time. Differential Revision: https://reviews.llvm.org/D32329 llvm-svn: 302739
2017-05-11 05:52:39 +08:00
# Prevent libc++abi from having library dependencies on libc++
add_definitions(-D_LIBCPP_DISABLE_EXTERN_TEMPLATE)
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-04 03:35:48 +08:00
if (MSVC)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
endif()
Allow libc++abi to be built without unwinder. This CL adds a new compilation flags LIBCXXABI_USE_LLVM_UNWINDER to specify whether the LLVM unwinder is enabled. Besides, all unwinder-specific code are guarded with this definition. Now, libc++abi will be able to use the unwinding routine from libgcc when LIBCXXABI_USE_LLVM_UNWINDER is disabled. llvm-svn: 226819
2015-01-22 21:27:36 +08:00
# Define LIBCXXABI_USE_LLVM_UNWINDER for conditional compilation.
[CMake] Fix libc++abi arm build w/o libunwind. This commit fixes libc++abi build when LLVM unwinder (libunwind_llvm) is not enabled. This commit fixes the problem by removing "LLVM_NATIVE_ARCH MATCHES ARM" from CMakeLists.txt so that LIBCXXABI_USE_LLVM_UNWINDER will only be defined when LLVM unwinder is enabled. We need LIBCXXABI_USE_LLVM_UNWINDER becase there is a subtle difference between the unwinder from libgcc and the one from libunwind_llvm. For the unwinder from libgcc, we have to initialize register r12 with the address of _Unwind_Control_Block; otherwise, _Unwind_GetLanguageSpecificData() and _Unwind_GetRegionStart() won't work properly. Consequently, there is an extra _Unwind_SetGR() when LLVM unwinder is disabled. Check cxa_personality.cpp for details. llvm-svn: 286759
2016-11-13 22:42:15 +08:00
if (LIBCXXABI_USE_LLVM_UNWINDER)
[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 19:42:01 +08:00
add_definitions(-DLIBCXXABI_USE_LLVM_UNWINDER)
Allow libc++abi to be built without unwinder. This CL adds a new compilation flags LIBCXXABI_USE_LLVM_UNWINDER to specify whether the LLVM unwinder is enabled. Besides, all unwinder-specific code are guarded with this definition. Now, libc++abi will be able to use the unwinding routine from libgcc when LIBCXXABI_USE_LLVM_UNWINDER is disabled. llvm-svn: 226819
2015-01-22 21:27:36 +08:00
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-14 03:22:26 +08: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 19:42:01 +08: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-22 05:27:14 +08: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 19:42:01 +08: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-14 03:22:26 +08:00
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-30 12:40:21 +08:00
if (LIBCXXABI_HAS_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 18:49:20 +08: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-30 12: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-19 04:37:53 +08: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 21:39:08 +08: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-04 03: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-10 01:44:44 +08:00
# On AIX, avoid picking up VMX extensions(i.e. vec_malloc) which would change
# the default alignment of the allocators here.
if (UNIX AND ${CMAKE_SYSTEM_NAME} MATCHES "AIX")
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-04 03: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-09 00: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)
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-04 03:35:48 +08:00
include_directories(include)
Fix syntax error in CMake created when a variable is not defined. llvm-svn: 236115
2015-04-29 23: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-03 01: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-09 00: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-12 03:12:58 +08: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-05 01: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-10 05: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-23 03:41:05 +08: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-09 00: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 22:03:54 +08:00
if (LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL-NOTFOUND")
set(LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL "")
endif()
if (NOT LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL STREQUAL "")
[cmake] Handle missing LIBUNWIND_* directories gracefully Add LIBUNWIND_* directories to include path only if they were actually found, in order to fix the CMake error. Both of the directories are usually unnecessary since libcxxabi uses only the common part of unwind.h that is supplied both by GCC and Clang. Differential Revision: https://reviews.llvm.org/D25314 llvm-svn: 292018
2017-01-15 01:05:16 +08:00
include_directories("${LIBCXXABI_LIBUNWIND_INCLUDES_INTERNAL}")
endif()
CMakeLists.txt cleanups: synchronize version with rest of LLVM, consistent spacing. Differential revision: https://reviews.llvm.org/D23092 llvm-svn: 278030
2016-08-09 01: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-04 03:35:48 +08:00
# Add source code. This also contains all of the logic for deciding linker flags
# soname, etc...
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-10 10: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-19 02:29:36 +08: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 17: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-10 10:20:11 +08:00
endif()