2020-03-25 09:33:42 +08:00
|
|
|
# See https://libcxx.llvm.org/docs/BuildingLibcxx.html for instructions on how
|
|
|
|
|
# to build libcxx with CMake.
|
2017-05-04 14:28:34 +08:00
|
|
|
|
2020-03-13 06:01:20 +08:00
|
|
|
if (NOT IS_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/../libcxxabi")
|
|
|
|
|
message(FATAL_ERROR "libc++ now requires being built in a monorepo layout with libcxxabi available")
|
|
|
|
|
endif()
|
|
|
|
|
|
2010-12-11 03:47:54 +08:00
|
|
|
#===============================================================================
|
|
|
|
|
# Setup Project
|
|
|
|
|
#===============================================================================
|
2020-04-22 23:15:05 +08:00
|
|
|
cmake_minimum_required(VERSION 3.13.4)
|
2010-12-11 03:47:54 +08:00
|
|
|
|
|
|
|
|
# Add path for custom modules
|
|
|
|
|
set(CMAKE_MODULE_PATH
|
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
|
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
|
2015-12-30 11:39:03 +08:00
|
|
|
${CMAKE_MODULE_PATH}
|
2010-12-11 03:47:54 +08:00
|
|
|
)
|
|
|
|
|
|
2021-01-25 16:50:03 +08:00
|
|
|
set(CMAKE_FOLDER "libc++")
|
|
|
|
|
|
2020-08-24 17:01:05 +08:00
|
|
|
set(LIBCXX_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
|
|
|
|
|
set(LIBCXX_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
|
|
|
|
|
set(LIBCXX_BINARY_INCLUDE_DIR "${LIBCXX_BINARY_DIR}/include/c++build")
|
|
|
|
|
|
2019-02-17 20:16:20 +08:00
|
|
|
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR LIBCXX_STANDALONE_BUILD)
|
2016-02-08 11:50:18 +08:00
|
|
|
project(libcxx CXX C)
|
|
|
|
|
|
|
|
|
|
set(PACKAGE_NAME libcxx)
|
2021-07-28 12:51:07 +08:00
|
|
|
set(PACKAGE_VERSION 14.0.0git)
|
2016-02-08 11:50:18 +08:00
|
|
|
set(PACKAGE_STRING "${PACKAGE_NAME} ${PACKAGE_VERSION}")
|
|
|
|
|
set(PACKAGE_BUGREPORT "llvm-bugs@lists.llvm.org")
|
2016-11-14 10:43:12 +08:00
|
|
|
|
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(LIBCXX_STANDALONE_BUILD 1)
|
|
|
|
|
set(LLVM_LIT_OUTPUT_DIR "${LIBCXX_BINARY_DIR}/bin")
|
|
|
|
|
|
2016-11-14 10:43:12 +08:00
|
|
|
# Find the LLVM sources and simulate LLVM CMake options.
|
|
|
|
|
include(HandleOutOfTreeLLVM)
|
2016-08-09 02:01:50 +08:00
|
|
|
endif()
|
2016-02-08 11:50:18 +08:00
|
|
|
|
2017-01-16 08:33:07 +08:00
|
|
|
if (LIBCXX_STANDALONE_BUILD)
|
2020-09-05 22:52:23 +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")
|
2020-04-29 03:50:12 +08:00
|
|
|
endif()
|
|
|
|
|
|
2020-09-05 22:52:23 +08:00
|
|
|
# Treat python2 as python3
|
|
|
|
|
add_executable(Python3::Interpreter IMPORTED)
|
|
|
|
|
set_target_properties(Python3::Interpreter PROPERTIES
|
|
|
|
|
IMPORTED_LOCATION ${Python2_EXECUTABLE})
|
|
|
|
|
set(Python3_EXECUTABLE ${Python2_EXECUTABLE})
|
2017-01-16 08:33:07 +08:00
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2016-02-08 11:50:18 +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."
|
|
|
|
|
)
|
2018-10-01 09:31:23 +08:00
|
|
|
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang" AND "${CMAKE_CXX_SIMULATE_ID}" STREQUAL "MSVC")
|
|
|
|
|
message(STATUS "Configuring for clang-cl")
|
|
|
|
|
set(LIBCXX_TARGETING_CLANG_CL ON)
|
|
|
|
|
endif()
|
2016-02-08 11:50:18 +08:00
|
|
|
|
2017-01-14 14:06:47 +08:00
|
|
|
if (MSVC)
|
|
|
|
|
set(LIBCXX_TARGETING_MSVC ON)
|
2018-10-01 09:00:11 +08:00
|
|
|
message(STATUS "Configuring for MSVC")
|
2017-01-14 14:06:47 +08:00
|
|
|
else()
|
|
|
|
|
set(LIBCXX_TARGETING_MSVC OFF)
|
|
|
|
|
endif()
|
|
|
|
|
|
2010-12-11 03:47:54 +08:00
|
|
|
#===============================================================================
|
|
|
|
|
# Setup CMake Options
|
|
|
|
|
#===============================================================================
|
2016-09-07 09:15:10 +08:00
|
|
|
include(CMakeDependentOption)
|
2017-03-11 11:24:18 +08:00
|
|
|
include(HandleCompilerRT)
|
2010-12-11 03:47:54 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Basic options ---------------------------------------------------------------
|
2017-02-05 07:22:28 +08:00
|
|
|
option(LIBCXX_ENABLE_ASSERTIONS "Enable assertions independent of build mode." OFF)
|
2015-07-30 07:46:55 +08:00
|
|
|
option(LIBCXX_ENABLE_SHARED "Build libc++ as a shared library." ON)
|
2016-08-09 06:57:25 +08:00
|
|
|
option(LIBCXX_ENABLE_STATIC "Build libc++ as a static library." ON)
|
2016-05-04 05:30:18 +08:00
|
|
|
option(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY "Build libc++experimental.a" ON)
|
2019-03-21 08:04:31 +08:00
|
|
|
set(ENABLE_FILESYSTEM_DEFAULT ON)
|
2020-11-05 06:13:22 +08:00
|
|
|
if (WIN32 AND NOT MINGW)
|
|
|
|
|
# Filesystem is buildable for windows, but it requires __int128 helper
|
|
|
|
|
# functions, that currently are provided by libgcc or compiler_rt builtins.
|
|
|
|
|
# These are available in MinGW environments, but not currently in MSVC
|
|
|
|
|
# environments.
|
2019-03-21 08:04:31 +08:00
|
|
|
set(ENABLE_FILESYSTEM_DEFAULT OFF)
|
|
|
|
|
endif()
|
|
|
|
|
option(LIBCXX_ENABLE_FILESYSTEM "Build filesystem as part of the main libc++ library"
|
|
|
|
|
${ENABLE_FILESYSTEM_DEFAULT})
|
2015-07-31 06:30:34 +08:00
|
|
|
option(LIBCXX_INCLUDE_TESTS "Build the libc++ tests." ${LLVM_INCLUDE_TESTS})
|
2019-08-06 02:29:14 +08:00
|
|
|
option(LIBCXX_ENABLE_PARALLEL_ALGORITHMS "Enable the parallel algorithms library. This requires the PSTL to be available." OFF)
|
2020-10-10 02:40:47 +08:00
|
|
|
option(LIBCXX_ENABLE_DEBUG_MODE_SUPPORT
|
2020-10-07 04:46:58 +08:00
|
|
|
"Whether to include support for libc++'s debugging mode in the library.
|
|
|
|
|
By default, this is turned on. If you turn it off and try to enable the
|
|
|
|
|
debug mode when compiling a program against libc++, it will fail to link
|
|
|
|
|
since the required support isn't provided in the library." ON)
|
2020-10-15 22:32:09 +08:00
|
|
|
option(LIBCXX_ENABLE_RANDOM_DEVICE
|
|
|
|
|
"Whether to include support for std::random_device in the library. Disabling
|
|
|
|
|
this can be useful when building the library for platforms that don't have
|
|
|
|
|
a source of randomness, such as some embedded platforms. When this is not
|
|
|
|
|
supported, most of <random> will still be available, but std::random_device
|
|
|
|
|
will not." ON)
|
2020-10-10 03:31:05 +08:00
|
|
|
option(LIBCXX_ENABLE_LOCALIZATION
|
|
|
|
|
"Whether to include support for localization in the library. Disabling
|
|
|
|
|
localization can be useful when porting to platforms that don't support
|
|
|
|
|
the C locale API (e.g. embedded). When localization is not supported,
|
|
|
|
|
several parts of the library will be disabled: <iostream>, <regex>, <locale>
|
|
|
|
|
will be completely unusable, and other parts may be only partly available." ON)
|
2021-05-26 02:11:08 +08:00
|
|
|
option(LIBCXX_ENABLE_UNICODE
|
|
|
|
|
"Whether to include support for Unicode in the library. Disabling Unicode can
|
2021-09-09 23:14:33 +08:00
|
|
|
be useful when porting to platforms that don't support UTF-8 encoding (e.g.
|
|
|
|
|
embedded)." ON)
|
2020-11-05 04:01:25 +08:00
|
|
|
option(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS
|
|
|
|
|
"Whether to turn on vendor availability annotations on declarations that depend
|
|
|
|
|
on definitions in a shared library. By default, we assume that we're not building
|
|
|
|
|
libc++ for any specific vendor, and we disable those annotations. Vendors wishing
|
|
|
|
|
to provide compile-time errors when using features unavailable on some version of
|
|
|
|
|
the shared library they shipped should turn this on and see `include/__availability`
|
|
|
|
|
for more details." OFF)
|
2021-07-25 15:18:53 +08:00
|
|
|
option(LIBCXX_ENABLE_INCOMPLETE_FEATURES
|
|
|
|
|
"Whether to enable support for incomplete library features. Incomplete features
|
|
|
|
|
are new library features under development. These features don't guarantee
|
|
|
|
|
ABI stability nor the quality of completed library features. Vendors
|
|
|
|
|
shipping the library may want to disable this option." ON)
|
2020-08-30 05:13:02 +08:00
|
|
|
set(LIBCXX_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/configs/legacy.cfg.in" CACHE STRING
|
2020-09-08 23:29:32 +08:00
|
|
|
"The Lit testing configuration to use when running the tests.")
|
2020-07-09 23:54:09 +08:00
|
|
|
set(LIBCXX_TEST_PARAMS "" CACHE STRING
|
|
|
|
|
"A list of parameters to run the Lit test suite with.")
|
2016-10-31 06:53:00 +08:00
|
|
|
|
|
|
|
|
# Benchmark options -----------------------------------------------------------
|
2018-09-23 05:30:12 +08:00
|
|
|
option(LIBCXX_INCLUDE_BENCHMARKS "Build the libc++ benchmarks and their dependencies" ON)
|
2018-11-15 04:38:46 +08:00
|
|
|
|
|
|
|
|
set(LIBCXX_BENCHMARK_TEST_ARGS_DEFAULT --benchmark_min_time=0.01)
|
|
|
|
|
set(LIBCXX_BENCHMARK_TEST_ARGS "${LIBCXX_BENCHMARK_TEST_ARGS_DEFAULT}" CACHE STRING
|
|
|
|
|
"Arguments to pass when running the benchmarks using check-cxx-benchmarks")
|
|
|
|
|
|
2016-10-31 06:53:00 +08:00
|
|
|
set(LIBCXX_BENCHMARK_NATIVE_STDLIB "" CACHE STRING
|
|
|
|
|
"Build the benchmarks against the specified native STL.
|
|
|
|
|
The value must be one of libc++/libstdc++")
|
|
|
|
|
set(LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN "" CACHE STRING
|
|
|
|
|
"Use alternate GCC toolchain when building the native benchmarks")
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_BENCHMARK_NATIVE_STDLIB)
|
|
|
|
|
if (NOT (LIBCXX_BENCHMARK_NATIVE_STDLIB STREQUAL "libc++"
|
|
|
|
|
OR LIBCXX_BENCHMARK_NATIVE_STDLIB STREQUAL "libstdc++"))
|
|
|
|
|
message(FATAL_ERROR "Invalid value for LIBCXX_BENCHMARK_NATIVE_STDLIB: "
|
|
|
|
|
"'${LIBCXX_BENCHMARK_NATIVE_STDLIB}'")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2015-08-23 03:40:49 +08:00
|
|
|
option(LIBCXX_INCLUDE_DOCS "Build the libc++ documentation." ${LLVM_INCLUDE_DOCS})
|
2015-07-31 06:30:34 +08:00
|
|
|
set(LIBCXX_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
|
|
|
|
|
"Define suffix of library directory name (32/64)")
|
|
|
|
|
option(LIBCXX_INSTALL_HEADERS "Install the libc++ headers." ON)
|
2015-08-27 04:18:21 +08:00
|
|
|
option(LIBCXX_INSTALL_LIBRARY "Install the libc++ library." ON)
|
2018-07-25 07:27:51 +08:00
|
|
|
cmake_dependent_option(LIBCXX_INSTALL_STATIC_LIBRARY
|
|
|
|
|
"Install the static libc++ library." ON
|
|
|
|
|
"LIBCXX_ENABLE_STATIC;LIBCXX_INSTALL_LIBRARY" OFF)
|
|
|
|
|
cmake_dependent_option(LIBCXX_INSTALL_SHARED_LIBRARY
|
|
|
|
|
"Install the shared libc++ library." ON
|
|
|
|
|
"LIBCXX_ENABLE_SHARED;LIBCXX_INSTALL_LIBRARY" OFF)
|
2016-09-07 09:15:10 +08:00
|
|
|
cmake_dependent_option(LIBCXX_INSTALL_EXPERIMENTAL_LIBRARY
|
|
|
|
|
"Install libc++experimental.a" ON
|
|
|
|
|
"LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY;LIBCXX_INSTALL_LIBRARY" OFF)
|
Implement <filesystem>
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
2018-07-27 11:07:09 +08:00
|
|
|
|
2018-09-26 16:24:51 +08:00
|
|
|
set(LIBCXX_ABI_VERSION "1" CACHE STRING "ABI version of libc++. Can be either 1 or 2, where 2 is currently not stable. Defaults to 1.")
|
2018-10-31 05:44:53 +08:00
|
|
|
set(LIBCXX_ABI_NAMESPACE "" CACHE STRING "The inline ABI namespace used by libc++. It defaults to __n where `n` is the current ABI version.")
|
2015-10-14 07:48:28 +08:00
|
|
|
option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
|
2017-10-05 10:18:08 +08:00
|
|
|
option(LIBCXX_ABI_FORCE_ITANIUM "Ignore auto-detection and force use of the Itanium ABI.")
|
|
|
|
|
option(LIBCXX_ABI_FORCE_MICROSOFT "Ignore auto-detection and force use of the Microsoft ABI.")
|
2019-05-29 10:21:37 +08:00
|
|
|
|
2020-11-17 07:13:43 +08:00
|
|
|
set(LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION "default" CACHE STRING
|
|
|
|
|
"Override the implementation to use for comparing typeinfos. By default, this
|
|
|
|
|
is detected automatically by the library, but this option allows overriding
|
|
|
|
|
which implementation is used unconditionally.
|
|
|
|
|
|
|
|
|
|
See the documentation in <libcxx/include/typeinfo> for details on what each
|
|
|
|
|
value means.")
|
|
|
|
|
set(TYPEINFO_COMPARISON_VALUES "default;1;2;3")
|
|
|
|
|
if (NOT ("${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}" IN_LIST TYPEINFO_COMPARISON_VALUES))
|
2020-05-16 03:58:19 +08:00
|
|
|
message(FATAL_ERROR "Value '${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}' is not a valid value for
|
2020-11-17 07:13:43 +08:00
|
|
|
LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION")
|
2019-05-29 10:21:37 +08:00
|
|
|
endif()
|
|
|
|
|
|
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
2018-08-16 20:44:28 +08:00
|
|
|
option(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT "Enable per TU ABI insulation by default. To be used by vendors." OFF)
|
2017-10-05 07:51:57 +08:00
|
|
|
set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header.")
|
2016-08-24 12:22:52 +08:00
|
|
|
option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
|
2019-03-21 02:16:24 +08:00
|
|
|
set(LIBCXX_LIBCPPABI_VERSION "2" CACHE STRING "Version of libc++abi's ABI to re-export from libc++ when re-exporting is enabled.
|
|
|
|
|
Note that this is not related to the version of libc++'s ABI itself!")
|
2015-07-31 06:30:34 +08:00
|
|
|
|
|
|
|
|
# ABI Library options ---------------------------------------------------------
|
2020-04-02 14:09:23 +08:00
|
|
|
set(LIBCXX_CXX_ABI "default" CACHE STRING "Specify C++ ABI library to use.")
|
2017-01-17 04:47:35 +08:00
|
|
|
set(CXXABIS none default libcxxabi libcxxrt libstdc++ libsupc++ vcruntime)
|
2015-07-31 06:30:34 +08:00
|
|
|
set_property(CACHE LIBCXX_CXX_ABI PROPERTY STRINGS ;${CXXABIS})
|
|
|
|
|
|
2015-10-23 04:54:27 +08:00
|
|
|
# Setup the default options if LIBCXX_CXX_ABI is not specified.
|
2017-01-03 09:18:48 +08:00
|
|
|
if (LIBCXX_CXX_ABI STREQUAL "default")
|
2017-04-21 07:33:49 +08:00
|
|
|
if (LIBCXX_TARGETING_MSVC)
|
|
|
|
|
# FIXME: Figure out how to configure the ABI library on Windows.
|
|
|
|
|
set(LIBCXX_CXX_ABI_LIBNAME "vcruntime")
|
Add default C++ ABI libname and include paths for FreeBSD
Summary:
As noted in a discussion about testing the LLVM 6.0.0 release candidates
(with libc++) for FreeBSD, many tests turned out to fail with
"exception_ptr not yet implemented". This was because libc++ did not
choose the correct C++ ABI library, and therefore it fell back to the
`exception_fallback.ipp` header.
Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library,
and its headers have always been installed in /usr/include/c++/v1,
together with the (system) libc++ headers. (Older versions of FreeBSD
used GNU libsupc++ by default, but these are now unsupported.)
Therefore, if we are building libc++ for FreeBSD, set:
* `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt"
* `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1"
by default.
Reviewers: emaste, EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: mgorny, cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D43166
llvm-svn: 324855
2018-02-12 06:31:05 +08:00
|
|
|
elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
|
|
|
|
|
set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
|
2020-04-02 14:09:23 +08:00
|
|
|
elseif (NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI)
|
|
|
|
|
set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
|
2016-08-09 02:01:50 +08:00
|
|
|
else()
|
2017-04-21 07:33:49 +08:00
|
|
|
set(LIBCXX_CXX_ABI_LIBNAME "default")
|
2016-08-09 02:01:50 +08:00
|
|
|
endif()
|
|
|
|
|
else()
|
2015-10-23 04:54:27 +08:00
|
|
|
set(LIBCXX_CXX_ABI_LIBNAME "${LIBCXX_CXX_ABI}")
|
2016-08-09 02:01:50 +08:00
|
|
|
endif()
|
2015-10-23 04:54:27 +08:00
|
|
|
|
2019-03-19 02:18:01 +08:00
|
|
|
option(LIBCXX_ENABLE_STATIC_ABI_LIBRARY
|
|
|
|
|
"Use a static copy of the ABI library when linking libc++.
|
|
|
|
|
This option cannot be used with LIBCXX_ENABLE_ABI_LINKER_SCRIPT." OFF)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2018-07-24 15:06:17 +08:00
|
|
|
cmake_dependent_option(LIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY
|
|
|
|
|
"Statically link the ABI library to static library" ON
|
|
|
|
|
"LIBCXX_ENABLE_STATIC_ABI_LIBRARY;LIBCXX_ENABLE_STATIC" OFF)
|
|
|
|
|
|
|
|
|
|
cmake_dependent_option(LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
|
|
|
|
|
"Statically link the ABI library to shared library" ON
|
2018-08-15 01:33:10 +08:00
|
|
|
"LIBCXX_ENABLE_STATIC_ABI_LIBRARY;LIBCXX_ENABLE_SHARED" OFF)
|
2018-07-24 15:06:17 +08:00
|
|
|
|
2015-10-15 03:54:03 +08:00
|
|
|
# Generate and install a linker script inplace of libc++.so. The linker script
|
2015-10-16 06:41:51 +08:00
|
|
|
# will link libc++ to the correct ABI library. This option is on by default
|
2017-03-25 11:22:35 +08:00
|
|
|
# on UNIX platforms other than Apple unless 'LIBCXX_ENABLE_STATIC_ABI_LIBRARY'
|
2015-10-23 04:50:07 +08:00
|
|
|
# is on. This option is also disabled when the ABI library is not specified
|
|
|
|
|
# or is specified to be "none".
|
2015-10-16 06:41:51 +08:00
|
|
|
set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE OFF)
|
2018-07-26 13:10:24 +08:00
|
|
|
if (LLVM_HAVE_LINK_VERSION_SCRIPT AND NOT LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
|
2015-10-23 04:54:27 +08:00
|
|
|
AND NOT LIBCXX_CXX_ABI_LIBNAME STREQUAL "none"
|
2017-01-03 09:18:48 +08:00
|
|
|
AND NOT LIBCXX_CXX_ABI_LIBNAME STREQUAL "default"
|
2020-04-29 09:37:28 +08:00
|
|
|
AND Python3_EXECUTABLE
|
2016-05-15 07:58:11 +08:00
|
|
|
AND LIBCXX_ENABLE_SHARED)
|
2015-10-16 06:41:51 +08:00
|
|
|
set(ENABLE_LINKER_SCRIPT_DEFAULT_VALUE ON)
|
|
|
|
|
endif()
|
|
|
|
|
|
2015-10-15 03:54:03 +08:00
|
|
|
option(LIBCXX_ENABLE_ABI_LINKER_SCRIPT
|
2015-10-16 06:41:51 +08:00
|
|
|
"Use and install a linker script for the given ABI library"
|
2015-10-16 07:04:54 +08:00
|
|
|
${ENABLE_LINKER_SCRIPT_DEFAULT_VALUE})
|
2015-10-15 03:54:03 +08:00
|
|
|
|
2017-03-03 03:35:33 +08:00
|
|
|
option(LIBCXX_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++ with definitions for operator new/delete. These are normally
|
|
|
|
|
defined in libc++abi, but this option can be used to define them in libc++
|
|
|
|
|
instead. If you define them in libc++, make sure they are NOT defined in
|
|
|
|
|
libc++abi. Doing otherwise is an ODR violation." OFF)
|
2015-07-31 06:30:34 +08:00
|
|
|
# Build libc++abi with libunwind. We need this option to determine whether to
|
|
|
|
|
# link with libunwind or libgcc_s while running the test cases.
|
|
|
|
|
option(LIBCXXABI_USE_LLVM_UNWINDER "Build and use the LLVM unwinder." OFF)
|
|
|
|
|
|
|
|
|
|
# Target options --------------------------------------------------------------
|
|
|
|
|
option(LIBCXX_BUILD_32_BITS "Build 32 bit libc++." ${LLVM_BUILD_32_BITS})
|
2021-07-15 03:54:13 +08:00
|
|
|
set(LIBCXX_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}" CACHE STRING "Use alternate target triple.")
|
2015-07-31 06:30:34 +08:00
|
|
|
set(LIBCXX_SYSROOT "" CACHE STRING "Use alternate sysroot.")
|
|
|
|
|
set(LIBCXX_GCC_TOOLCHAIN "" CACHE STRING "Use alternate GCC toolchain.")
|
|
|
|
|
|
|
|
|
|
# Feature options -------------------------------------------------------------
|
|
|
|
|
option(LIBCXX_ENABLE_EXCEPTIONS "Use exceptions." ON)
|
|
|
|
|
option(LIBCXX_ENABLE_RTTI "Use run time type information." ON)
|
2014-12-07 05:02:58 +08:00
|
|
|
option(LIBCXX_ENABLE_THREADS "Build libc++ with support for threads." ON)
|
|
|
|
|
option(LIBCXX_ENABLE_MONOTONIC_CLOCK
|
|
|
|
|
"Build libc++ with support for a monotonic clock.
|
2015-08-25 05:20:07 +08:00
|
|
|
This option may only be set to OFF when LIBCXX_ENABLE_THREADS=OFF." ON)
|
2015-11-09 18:21:04 +08:00
|
|
|
option(LIBCXX_HAS_MUSL_LIBC "Build libc++ with support for the Musl C library" OFF)
|
2016-05-26 01:40:09 +08:00
|
|
|
option(LIBCXX_HAS_PTHREAD_API "Ignore auto-detection and force use of pthread API" OFF)
|
2018-01-06 04:48:29 +08:00
|
|
|
option(LIBCXX_HAS_WIN32_THREAD_API "Ignore auto-detection and force use of win32 thread API" OFF)
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
option(LIBCXX_HAS_EXTERNAL_THREAD_API
|
|
|
|
|
"Build libc++ with an externalized threading API.
|
|
|
|
|
This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON." OFF)
|
2017-01-07 04:05:40 +08:00
|
|
|
option(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
|
|
|
|
|
"Build libc++ with an externalized threading library.
|
|
|
|
|
This option may only be set to ON when LIBCXX_ENABLE_THREADS=ON" OFF)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
|
|
|
|
# Misc options ----------------------------------------------------------------
|
2015-10-10 11:34:52 +08:00
|
|
|
# FIXME: Turn -pedantic back ON. It is currently off because it warns
|
|
|
|
|
# about #include_next which is used everywhere.
|
|
|
|
|
option(LIBCXX_ENABLE_PEDANTIC "Compile with pedantic enabled." OFF)
|
2015-07-31 06:30:34 +08:00
|
|
|
option(LIBCXX_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
|
2016-07-12 22:39:13 +08:00
|
|
|
option(LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS "Disable #warnings about conflicting macros." OFF)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2015-03-31 12:15:45 +08:00
|
|
|
option(LIBCXX_GENERATE_COVERAGE "Enable generating code coverage." OFF)
|
|
|
|
|
set(LIBCXX_COVERAGE_LIBRARY "" CACHE STRING
|
2015-07-31 06:30:34 +08:00
|
|
|
"The Profile-rt library used to build with code coverage")
|
|
|
|
|
|
2015-12-17 07:41:05 +08:00
|
|
|
set(LIBCXX_CONFIGURE_IDE_DEFAULT OFF)
|
|
|
|
|
if (XCODE OR MSVC_IDE)
|
|
|
|
|
set(LIBCXX_CONFIGURE_IDE_DEFAULT ON)
|
|
|
|
|
endif()
|
|
|
|
|
option(LIBCXX_CONFIGURE_IDE "Configure libcxx for use within an IDE"
|
|
|
|
|
${LIBCXX_CONFIGURE_IDE_DEFAULT})
|
|
|
|
|
|
2019-01-06 14:14:31 +08:00
|
|
|
option(LIBCXX_HERMETIC_STATIC_LIBRARY
|
|
|
|
|
"Do not export any symbols from the static library." OFF)
|
|
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
#===============================================================================
|
|
|
|
|
# Check option configurations
|
|
|
|
|
#===============================================================================
|
|
|
|
|
|
|
|
|
|
# Ensure LIBCXX_ENABLE_MONOTONIC_CLOCK is set to ON only when
|
|
|
|
|
# LIBCXX_ENABLE_THREADS is on.
|
|
|
|
|
if(LIBCXX_ENABLE_THREADS AND NOT LIBCXX_ENABLE_MONOTONIC_CLOCK)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_ENABLE_MONOTONIC_CLOCK can only be set to OFF"
|
|
|
|
|
" when LIBCXX_ENABLE_THREADS is also set to OFF.")
|
2015-07-30 05:07:28 +08:00
|
|
|
endif()
|
|
|
|
|
|
2017-01-03 20:59:50 +08:00
|
|
|
if(NOT LIBCXX_ENABLE_THREADS)
|
|
|
|
|
if(LIBCXX_HAS_PTHREAD_API)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_HAS_PTHREAD_API can only be set to ON"
|
|
|
|
|
" when LIBCXX_ENABLE_THREADS is also set to ON.")
|
|
|
|
|
endif()
|
|
|
|
|
if(LIBCXX_HAS_EXTERNAL_THREAD_API)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_HAS_EXTERNAL_THREAD_API can only be set to ON"
|
|
|
|
|
" when LIBCXX_ENABLE_THREADS is also set to ON.")
|
|
|
|
|
endif()
|
2017-01-07 04:05:40 +08:00
|
|
|
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY can only be set "
|
|
|
|
|
"to ON when LIBCXX_ENABLE_THREADS is also set to ON.")
|
|
|
|
|
endif()
|
2018-01-06 04:48:29 +08:00
|
|
|
if (LIBCXX_HAS_WIN32_THREAD_API)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_HAS_WIN32_THREAD_API can only be set to ON"
|
|
|
|
|
" when LIBCXX_ENABLE_THREADS is also set to ON.")
|
|
|
|
|
endif()
|
2017-01-07 04:05:40 +08:00
|
|
|
|
|
|
|
|
endif()
|
|
|
|
|
|
2017-01-09 18:38:56 +08:00
|
|
|
if (LIBCXX_HAS_EXTERNAL_THREAD_API)
|
|
|
|
|
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
|
|
|
|
|
message(FATAL_ERROR "The options LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY and "
|
|
|
|
|
"LIBCXX_HAS_EXTERNAL_THREAD_API cannot both be ON at "
|
|
|
|
|
"the same time")
|
|
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_HAS_PTHREAD_API)
|
|
|
|
|
message(FATAL_ERROR "The options LIBCXX_HAS_EXTERNAL_THREAD_API"
|
|
|
|
|
"and LIBCXX_HAS_PTHREAD_API cannot be both"
|
|
|
|
|
"set to ON at the same time.")
|
|
|
|
|
endif()
|
2018-01-06 04:48:29 +08:00
|
|
|
if (LIBCXX_HAS_WIN32_THREAD_API)
|
|
|
|
|
message(FATAL_ERROR "The options LIBCXX_HAS_EXTERNAL_THREAD_API"
|
|
|
|
|
"and LIBCXX_HAS_WIN32_THREAD_API cannot be both"
|
|
|
|
|
"set to ON at the same time.")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_PTHREAD_API)
|
|
|
|
|
if (LIBCXX_HAS_WIN32_THREAD_API)
|
|
|
|
|
message(FATAL_ERROR "The options LIBCXX_HAS_PTHREAD_API"
|
|
|
|
|
"and LIBCXX_HAS_WIN32_THREAD_API cannot be both"
|
|
|
|
|
"set to ON at the same time.")
|
|
|
|
|
endif()
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
endif()
|
|
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Ensure LLVM_USE_SANITIZER is not specified when LIBCXX_GENERATE_COVERAGE
|
|
|
|
|
# is ON.
|
|
|
|
|
if (LLVM_USE_SANITIZER AND LIBCXX_GENERATE_COVERAGE)
|
|
|
|
|
message(FATAL_ERROR "LLVM_USE_SANITIZER cannot be used with LIBCXX_GENERATE_COVERAGE")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
# Set LIBCXX_BUILD_32_BITS to (LIBCXX_BUILD_32_BITS OR LLVM_BUILD_32_BITS)
|
|
|
|
|
# and check that we can build with 32 bits if requested.
|
|
|
|
|
if (CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32)
|
|
|
|
|
if (LIBCXX_BUILD_32_BITS AND NOT LLVM_BUILD_32_BITS) # Don't duplicate the output from LLVM
|
|
|
|
|
message(STATUS "Building 32 bits executables and libraries.")
|
|
|
|
|
endif()
|
|
|
|
|
elseif(LIBCXX_BUILD_32_BITS)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_BUILD_32_BITS=ON is not supported on this platform.")
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-03-25 22:56:29 +08:00
|
|
|
# Warn users that LIBCXX_ENABLE_STATIC_ABI_LIBRARY is an experimental option.
|
2015-03-03 23:59:51 +08:00
|
|
|
if (LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
|
2019-03-25 22:56:29 +08:00
|
|
|
message(WARNING "LIBCXX_ENABLE_STATIC_ABI_LIBRARY is an experimental option")
|
2020-04-29 09:37:28 +08:00
|
|
|
if (LIBCXX_ENABLE_STATIC AND NOT Python3_EXECUTABLE)
|
2016-11-19 03:53:45 +08:00
|
|
|
message(FATAL_ERROR "LIBCXX_ENABLE_STATIC_ABI_LIBRARY requires python but it was not found.")
|
|
|
|
|
endif()
|
2015-03-03 23:59:51 +08:00
|
|
|
endif()
|
|
|
|
|
|
2015-10-15 03:54:03 +08:00
|
|
|
if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
|
|
|
|
|
if (APPLE)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT cannot be used on APPLE targets")
|
|
|
|
|
endif()
|
2016-05-15 07:58:11 +08:00
|
|
|
if (NOT LIBCXX_ENABLE_SHARED)
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_ENABLE_ABI_LINKER_SCRIPT is only available for shared library builds.")
|
|
|
|
|
endif()
|
2015-10-15 03:54:03 +08:00
|
|
|
endif()
|
|
|
|
|
|
2018-07-26 13:10:24 +08:00
|
|
|
if (LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY AND LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
|
2015-10-15 03:54:03 +08:00
|
|
|
message(FATAL_ERROR "Conflicting options given.
|
|
|
|
|
LIBCXX_ENABLE_STATIC_ABI_LIBRARY cannot be specified with
|
|
|
|
|
LIBCXX_ENABLE_ABI_LINKER_SCRIPT")
|
|
|
|
|
endif()
|
|
|
|
|
|
2017-10-05 10:18:08 +08:00
|
|
|
if (LIBCXX_ABI_FORCE_ITANIUM AND LIBCXX_ABI_FORCE_MICROSOFT)
|
|
|
|
|
message(FATAL_ERROR "Only one of LIBCXX_ABI_FORCE_ITANIUM and LIBCXX_ABI_FORCE_MICROSOFT can be specified.")
|
2017-10-05 07:44:38 +08:00
|
|
|
endif ()
|
|
|
|
|
|
2010-12-11 03:47:54 +08:00
|
|
|
#===============================================================================
|
|
|
|
|
# Configure System
|
|
|
|
|
#===============================================================================
|
|
|
|
|
|
2020-06-27 00:08:59 +08:00
|
|
|
# TODO: Projects that depend on libc++ should use LIBCXX_GENERATED_INCLUDE_DIR
|
|
|
|
|
# instead of hard-coding include/c++/v1.
|
2018-06-28 11:11:52 +08:00
|
|
|
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
|
2021-04-17 12:33:18 +08:00
|
|
|
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/${LLVM_DEFAULT_TARGET_TRIPLE})
|
2020-06-27 00:08:59 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
|
2020-07-16 05:10:56 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LLVM_BINARY_DIR}/include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1")
|
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(LIBCXX_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX}/${LLVM_DEFAULT_TARGET_TRIPLE} CACHE PATH
|
|
|
|
|
"Path where built libc++ libraries should be installed.")
|
2021-08-11 18:44:06 +08:00
|
|
|
set(LIBCXX_INSTALL_RUNTIME_DIR bin CACHE PATH
|
|
|
|
|
"Path where built libc++ runtime libraries should be installed.")
|
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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1" CACHE PATH
|
|
|
|
|
"Path where target-agnostic libc++ headers should be installed.")
|
|
|
|
|
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "include/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1" CACHE PATH
|
|
|
|
|
"Path where target-specific libc++ headers should be installed.")
|
2019-05-23 05:08:33 +08:00
|
|
|
if(LIBCXX_LIBDIR_SUBDIR)
|
|
|
|
|
string(APPEND LIBCXX_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
|
|
|
|
|
string(APPEND LIBCXX_INSTALL_LIBRARY_DIR /${LIBCXX_LIBDIR_SUBDIR})
|
|
|
|
|
endif()
|
2018-06-28 11:11:52 +08:00
|
|
|
elseif(LLVM_LIBRARY_OUTPUT_INTDIR)
|
2017-05-04 14:02:50 +08:00
|
|
|
set(LIBCXX_LIBRARY_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR})
|
2020-06-27 00:08:59 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1")
|
2020-07-16 05:10:56 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
|
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(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX} CACHE PATH
|
|
|
|
|
"Path where built libc++ libraries should be installed.")
|
2021-08-11 18:44:06 +08:00
|
|
|
set(LIBCXX_INSTALL_RUNTIME_DIR bin CACHE PATH
|
|
|
|
|
"Path where built libc++ runtime libraries should be installed.")
|
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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1" CACHE PATH
|
|
|
|
|
"Path where target-agnostic libc++ headers should be installed.")
|
|
|
|
|
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}" CACHE PATH
|
|
|
|
|
"Path where target-specific libc++ headers should be installed.")
|
2017-05-04 14:02:50 +08:00
|
|
|
else()
|
|
|
|
|
set(LIBCXX_LIBRARY_DIR ${CMAKE_BINARY_DIR}/lib${LIBCXX_LIBDIR_SUFFIX})
|
2020-06-27 00:08:59 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1")
|
2020-07-16 05:10:56 +08:00
|
|
|
set(LIBCXX_GENERATED_INCLUDE_TARGET_DIR "${LIBCXX_GENERATED_INCLUDE_DIR}")
|
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(LIBCXX_INSTALL_LIBRARY_DIR lib${LIBCXX_LIBDIR_SUFFIX} CACHE PATH
|
|
|
|
|
"Path where built libc++ libraries should be installed.")
|
2021-08-11 18:44:06 +08:00
|
|
|
set(LIBCXX_INSTALL_RUNTIME_DIR bin CACHE PATH
|
|
|
|
|
"Path where built libc++ runtime libraries should be installed.")
|
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(LIBCXX_INSTALL_INCLUDE_DIR "include/c++/v1" CACHE PATH
|
|
|
|
|
"Path where target-agnostic libc++ headers should be installed.")
|
|
|
|
|
set(LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}" CACHE PATH
|
|
|
|
|
"Path where target-specific libc++ headers should be installed.")
|
2017-05-04 14:02:50 +08:00
|
|
|
endif()
|
2018-06-28 11:11:52 +08:00
|
|
|
|
2017-01-17 04:47:35 +08:00
|
|
|
file(MAKE_DIRECTORY "${LIBCXX_BINARY_INCLUDE_DIR}")
|
2014-12-20 11:16:55 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
|
|
|
|
|
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
|
2017-04-14 00:27:38 +08:00
|
|
|
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LIBCXX_LIBRARY_DIR})
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2014-11-15 14:26:30 +08:00
|
|
|
# Declare libc++ configuration variables.
|
|
|
|
|
# They are intended for use as follows:
|
|
|
|
|
# LIBCXX_CXX_FLAGS: General flags for both the compiler and linker.
|
|
|
|
|
# LIBCXX_COMPILE_FLAGS: Compile only flags.
|
|
|
|
|
# LIBCXX_LINK_FLAGS: Linker only flags.
|
2016-10-10 05:34:03 +08:00
|
|
|
# LIBCXX_LIBRARIES: libraries libc++ is linked to.
|
2014-11-15 14:26:30 +08:00
|
|
|
set(LIBCXX_COMPILE_FLAGS "")
|
|
|
|
|
set(LIBCXX_LINK_FLAGS "")
|
2015-07-31 06:30:34 +08:00
|
|
|
set(LIBCXX_LIBRARIES "")
|
2014-11-15 14:26:30 +08:00
|
|
|
|
2016-06-02 09:10:08 +08:00
|
|
|
# Include macros for adding and removing libc++ flags.
|
|
|
|
|
include(HandleLibcxxFlags)
|
|
|
|
|
|
|
|
|
|
# Target flags ================================================================
|
|
|
|
|
# These flags get added to CMAKE_CXX_FLAGS and CMAKE_C_FLAGS so that
|
|
|
|
|
# 'config-ix' use them during feature checks. It also adds them to both
|
|
|
|
|
# 'LIBCXX_COMPILE_FLAGS' and 'LIBCXX_LINK_FLAGS'
|
|
|
|
|
add_target_flags_if(LIBCXX_BUILD_32_BITS "-m32")
|
[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(LIBCXX_TARGET_TRIPLE)
|
2021-07-16 01:02:43 +08:00
|
|
|
add_target_flags_if_supported("--target=${LIBCXX_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
|
|
|
elseif(CMAKE_CXX_COMPILER_TARGET)
|
|
|
|
|
set(LIBCXX_TARGET_TRIPLE "${CMAKE_CXX_COMPILER_TARGET}")
|
|
|
|
|
endif()
|
|
|
|
|
if(LIBCXX_SYSROOT)
|
2021-07-16 01:02:43 +08:00
|
|
|
add_target_flags_if_supported("--sysroot=${LIBCXX_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
|
|
|
elseif(CMAKE_SYSROOT)
|
|
|
|
|
set(LIBCXX_SYSROOT "${CMAKE_SYSROOT}")
|
|
|
|
|
endif()
|
|
|
|
|
if(LIBCXX_GCC_TOOLCHAIN)
|
2021-07-16 01:02:43 +08:00
|
|
|
add_target_flags_if_supported("--gcc-toolchain=${LIBCXX_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
|
|
|
elseif(CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN)
|
|
|
|
|
set(LIBCXX_GCC_TOOLCHAIN "${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}")
|
|
|
|
|
endif()
|
|
|
|
|
|
2014-11-16 01:25:23 +08:00
|
|
|
# Configure compiler.
|
|
|
|
|
include(config-ix)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2015-03-31 12:15:45 +08:00
|
|
|
# Configure coverage options.
|
|
|
|
|
if (LIBCXX_GENERATE_COVERAGE)
|
|
|
|
|
include(CodeCoverage)
|
|
|
|
|
set(CMAKE_BUILD_TYPE "COVERAGE" CACHE STRING "" FORCE)
|
|
|
|
|
endif()
|
2014-11-16 01:25:23 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
|
2017-01-14 15:54:39 +08:00
|
|
|
if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG")
|
|
|
|
|
set(LIBCXX_DEBUG_BUILD ON)
|
|
|
|
|
else()
|
|
|
|
|
set(LIBCXX_DEBUG_BUILD OFF)
|
|
|
|
|
endif()
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2014-11-16 01:25:23 +08:00
|
|
|
#===============================================================================
|
|
|
|
|
# Setup Compiler Flags
|
|
|
|
|
#===============================================================================
|
|
|
|
|
|
2016-03-05 22:22:02 +08:00
|
|
|
include(HandleLibCXXABI) # Setup the ABI library flags
|
2015-07-29 08:03:51 +08:00
|
|
|
|
2016-09-27 15:55:26 +08:00
|
|
|
if (NOT LIBCXX_STANDALONE_BUILD)
|
|
|
|
|
# Remove flags that may have snuck in.
|
|
|
|
|
remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
|
2017-01-18 07:27:56 +08:00
|
|
|
-lc++abi)
|
2016-09-27 15:55:26 +08:00
|
|
|
endif()
|
2020-10-13 22:05:00 +08:00
|
|
|
remove_flags(--stdlib=libc++ -stdlib=libc++ --stdlib=libstdc++ -stdlib=libstdc++)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2017-01-14 14:06:47 +08:00
|
|
|
# FIXME: Remove all debug flags and flags that change which Windows
|
|
|
|
|
# default libraries are linked. Currently we only support linking the
|
|
|
|
|
# non-debug DLLs
|
2017-01-14 15:54:39 +08:00
|
|
|
remove_flags("/D_DEBUG" "/MTd" "/MDd" "/MT" "/Md")
|
2017-01-14 14:06:47 +08:00
|
|
|
|
2017-03-25 11:42:20 +08:00
|
|
|
# FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
|
2015-10-16 04:27:15 +08:00
|
|
|
# Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
|
2017-03-25 11:42:20 +08:00
|
|
|
# so they don't get transformed into -Wno and -errors respectively.
|
2015-10-16 04:27:15 +08:00
|
|
|
remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
|
2015-10-14 07:56:33 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Required flags ==============================================================
|
2019-10-03 04:07:01 +08:00
|
|
|
function(cxx_add_basic_build_flags target)
|
2019-12-12 09:26:30 +08:00
|
|
|
|
2020-11-22 22:56:39 +08:00
|
|
|
# Require C++20 for all targets. C++17 is needed to use aligned allocation
|
|
|
|
|
# in the dylib. C++20 is needed to use char8_t.
|
2019-12-12 09:26:30 +08:00
|
|
|
set_target_properties(${target} PROPERTIES
|
2020-11-22 22:56:39 +08:00
|
|
|
CXX_STANDARD 20
|
2021-09-24 00:15:02 +08:00
|
|
|
CXX_STANDARD_REQUIRED YES
|
2019-12-12 09:26:30 +08:00
|
|
|
CXX_EXTENSIONS NO)
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2020-07-23 23:05:47 +08:00
|
|
|
# When building the dylib, don't warn for unavailable aligned allocation
|
|
|
|
|
# functions based on the deployment target -- they are always available
|
2020-11-13 03:40:35 +08:00
|
|
|
# because they are provided by the dylib itself with the excepton of z/OS.
|
|
|
|
|
if (ZOS)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -fno-aligned-allocation)
|
|
|
|
|
else()
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -faligned-allocation)
|
|
|
|
|
endif()
|
2020-07-23 23:05:47 +08:00
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
# On all systems the system c++ standard library headers need to be excluded.
|
|
|
|
|
# MSVC only has -X, which disables all default includes; including the crt.
|
|
|
|
|
# Thus, we do nothing and hope we don't accidentally include any of the C++
|
|
|
|
|
# headers
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -nostdinc++)
|
|
|
|
|
|
|
|
|
|
# Hide all inline function definitions which have not explicitly been marked
|
|
|
|
|
# visible. This prevents new definitions for inline functions from appearing in
|
|
|
|
|
# the dylib when get ODR used by another function.
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -fvisibility-inlines-hidden)
|
|
|
|
|
|
|
|
|
|
# Our visibility annotations are not quite right for non-Clang compilers,
|
|
|
|
|
# so we end up not exporting all the symbols we should. In the future, we
|
|
|
|
|
# can improve the situation by providing an explicit list of exported
|
|
|
|
|
# symbols on all compilers.
|
|
|
|
|
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -fvisibility=hidden)
|
|
|
|
|
endif()
|
[libcxx] Build with -fvisibility-inlines-hidden -- Remove 20 inline definitions from the dylib
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
2016-10-26 03:43:44 +08:00
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
if (LIBCXX_CONFIGURE_IDE)
|
|
|
|
|
# This simply allows IDE to process <experimental/coroutine>
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -fcoroutines-ts)
|
|
|
|
|
endif()
|
2017-05-25 12:36:24 +08:00
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
# Let the library headers know they are currently being used to build the
|
|
|
|
|
# library.
|
|
|
|
|
target_compile_definitions(${target} PRIVATE -D_LIBCPP_BUILDING_LIBRARY)
|
[libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI compatibility
Summary:
GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'.
```
// RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
// RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out
#define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline))
template <class T>
struct Foo {
void foo();
void bar();
};
template <class T>
void Foo<T>::foo() {}
template <class T>
inline INLINE_VISIBILITY
void Foo<T>::bar() {}
template struct Foo<int>;
```
This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated).
Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors).
This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`.
After applying this patch GCC dylibs now contain:
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl`
* `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_`
* `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl`
* `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE`
* `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw`
* `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl`
* `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E`
* `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl`
* `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw`
This patch has no effect on Clang based builds.
Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF
Subscribers: beanz, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D24600
llvm-svn: 281681
2016-09-16 08:00:48 +08:00
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
if (NOT LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS)
|
|
|
|
|
target_compile_definitions(${target} PRIVATE -D_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS)
|
|
|
|
|
endif()
|
2017-03-03 03:35:33 +08:00
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
if (LIBCXX_HAS_COMMENT_LIB_PRAGMA)
|
2019-12-02 18:49:20 +08:00
|
|
|
if (LIBCXX_HAS_PTHREAD_LIB)
|
|
|
|
|
target_compile_definitions(${target} PRIVATE -D_LIBCPP_LINK_PTHREAD_LIB)
|
|
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_HAS_RT_LIB)
|
|
|
|
|
target_compile_definitions(${target} PRIVATE -D_LIBCPP_LINK_RT_LIB)
|
|
|
|
|
endif()
|
2019-10-03 04:07:01 +08:00
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2019-05-30 12:40:21 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Warning flags ===============================================================
|
2019-10-03 03:31:30 +08:00
|
|
|
function(cxx_add_warning_flags target)
|
|
|
|
|
target_compile_definitions(${target} PUBLIC -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
|
2021-03-05 20:46:30 +08:00
|
|
|
if (MSVC)
|
|
|
|
|
# -W4 is the cl.exe/clang-cl equivalent of -Wall. (In cl.exe and clang-cl,
|
|
|
|
|
# -Wall is equivalent to -Weverything in GCC style compiler drivers.)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -W4)
|
|
|
|
|
else()
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -Wall)
|
|
|
|
|
endif()
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -Wextra -W -Wwrite-strings
|
2019-10-03 03:31:30 +08:00
|
|
|
-Wno-unused-parameter -Wno-long-long
|
2021-04-01 14:29:55 +08:00
|
|
|
-Werror=return-type -Wextra-semi -Wundef)
|
2019-10-03 03:31:30 +08:00
|
|
|
if ("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang")
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE
|
|
|
|
|
-Wno-user-defined-literals
|
|
|
|
|
-Wno-covered-switch-default
|
2020-07-23 08:44:52 +08:00
|
|
|
-Wno-suggest-override
|
2019-10-03 03:31:30 +08:00
|
|
|
)
|
2018-10-01 09:15:50 +08:00
|
|
|
if (LIBCXX_TARGETING_CLANG_CL)
|
2019-10-03 03:31:30 +08:00
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE
|
2018-10-01 09:15:50 +08:00
|
|
|
-Wno-c++98-compat
|
2018-10-01 09:31:23 +08:00
|
|
|
-Wno-c++98-compat-pedantic
|
2018-10-01 09:15:50 +08:00
|
|
|
-Wno-c++11-compat
|
|
|
|
|
-Wno-undef
|
2018-10-01 09:31:23 +08:00
|
|
|
-Wno-reserved-id-macro
|
|
|
|
|
-Wno-gnu-include-next
|
|
|
|
|
-Wno-gcc-compat # For ignoring "'diagnose_if' is a clang extension" warnings
|
2018-10-01 09:47:23 +08:00
|
|
|
-Wno-zero-as-null-pointer-constant # FIXME: Remove this and fix all occurrences.
|
|
|
|
|
-Wno-deprecated-dynamic-exception-spec # For auto_ptr
|
|
|
|
|
-Wno-sign-conversion
|
|
|
|
|
-Wno-old-style-cast
|
|
|
|
|
-Wno-deprecated # FIXME: Remove this and fix all occurrences.
|
2018-10-01 09:59:37 +08:00
|
|
|
-Wno-shift-sign-overflow # FIXME: Why do we need this with clang-cl but not clang?
|
2018-10-01 11:59:05 +08:00
|
|
|
-Wno-double-promotion # FIXME: remove me
|
2018-10-01 09:15:50 +08:00
|
|
|
)
|
|
|
|
|
endif()
|
2019-10-03 03:31:30 +08:00
|
|
|
elseif("${CMAKE_CXX_COMPILER_ID}" MATCHES "GNU")
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE
|
|
|
|
|
-Wno-literal-suffix
|
|
|
|
|
-Wno-c++14-compat
|
2020-07-23 08:44:52 +08:00
|
|
|
-Wno-noexcept-type
|
|
|
|
|
-Wno-suggest-override)
|
2019-10-03 03:31:30 +08:00
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_ENABLE_WERROR)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -Werror)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -WX)
|
|
|
|
|
else()
|
|
|
|
|
# TODO(EricWF) Remove this. We shouldn't be suppressing errors when -Werror is
|
|
|
|
|
# added elsewhere.
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -Wno-error)
|
|
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_ENABLE_PEDANTIC)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE -pedantic)
|
|
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_DISABLE_MACRO_CONFLICT_WARNINGS)
|
|
|
|
|
target_compile_definitions(${target} PRIVATE -D_LIBCPP_DISABLE_MACRO_CONFLICT_WARNINGS)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2010-12-11 03:47:54 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Exception flags =============================================================
|
2019-10-05 02:03:17 +08:00
|
|
|
function(cxx_add_exception_flags target)
|
|
|
|
|
if (LIBCXX_ENABLE_EXCEPTIONS)
|
|
|
|
|
# Catches C++ exceptions only and tells the compiler to assume that extern C
|
|
|
|
|
# functions never throw a C++ exception.
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -EHsc)
|
|
|
|
|
else()
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -EHs- -EHa-)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -fno-exceptions)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2015-07-31 06:30:34 +08:00
|
|
|
|
|
|
|
|
# RTTI flags ==================================================================
|
2019-10-05 02:03:17 +08:00
|
|
|
function(cxx_add_rtti_flags target)
|
|
|
|
|
if (NOT LIBCXX_ENABLE_RTTI)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -GR-)
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -fno-rtti)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2015-07-31 06:30:34 +08:00
|
|
|
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
# Threading flags =============================================================
|
2017-01-09 18:38:56 +08:00
|
|
|
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY AND LIBCXX_ENABLE_SHARED)
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
# Need to allow unresolved symbols if this is to work with shared library builds
|
|
|
|
|
if (APPLE)
|
|
|
|
|
add_link_flags("-undefined dynamic_lookup")
|
|
|
|
|
else()
|
|
|
|
|
# Relax this restriction from HandleLLVMOptions
|
|
|
|
|
string(REPLACE "-Wl,-z,defs" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
|
|
|
|
|
endif()
|
|
|
|
|
endif()
|
|
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
# Assertion flags =============================================================
|
|
|
|
|
define_if(LIBCXX_ENABLE_ASSERTIONS -UNDEBUG)
|
|
|
|
|
define_if_not(LIBCXX_ENABLE_ASSERTIONS -DNDEBUG)
|
2017-02-05 07:22:28 +08:00
|
|
|
define_if(LIBCXX_ENABLE_ASSERTIONS -D_LIBCPP_DEBUG=0)
|
2017-01-14 15:54:39 +08:00
|
|
|
define_if(LIBCXX_DEBUG_BUILD -D_DEBUG)
|
|
|
|
|
if (LIBCXX_ENABLE_ASSERTIONS AND NOT LIBCXX_DEBUG_BUILD)
|
2010-12-11 03:47:54 +08:00
|
|
|
# MSVC doesn't like _DEBUG on release builds. See PR 4379.
|
2017-01-14 14:06:47 +08:00
|
|
|
define_if_not(LIBCXX_TARGETING_MSVC -D_DEBUG)
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
|
|
|
|
|
2016-10-14 20:56:52 +08:00
|
|
|
# Modules flags ===============================================================
|
|
|
|
|
# FIXME The libc++ sources are fundamentally non-modular. They need special
|
|
|
|
|
# versions of the headers in order to provide C++03 and legacy ABI definitions.
|
|
|
|
|
# NOTE: The public headers can be used with modules in all other contexts.
|
2019-10-05 02:03:17 +08:00
|
|
|
function(cxx_add_module_flags target)
|
|
|
|
|
if (LLVM_ENABLE_MODULES)
|
|
|
|
|
# Ignore that the rest of the modules flags are now unused.
|
2019-10-05 03:10:56 +08:00
|
|
|
target_add_compile_flags_if_supported(${target} PUBLIC -Wno-unused-command-line-argument)
|
|
|
|
|
target_compile_options(${target} PUBLIC -fno-modules)
|
2019-10-05 02:03:17 +08:00
|
|
|
endif()
|
|
|
|
|
endfunction()
|
2016-10-14 20:56:52 +08:00
|
|
|
|
2015-08-25 05:20:07 +08:00
|
|
|
# Sanitizer flags =============================================================
|
2010-12-11 03:47:54 +08:00
|
|
|
|
2018-11-14 07:08:31 +08:00
|
|
|
function(get_sanitizer_flags OUT_VAR USE_SANITIZER)
|
|
|
|
|
set(SANITIZER_FLAGS)
|
|
|
|
|
set(USE_SANITIZER "${USE_SANITIZER}")
|
2015-07-30 07:46:55 +08:00
|
|
|
# NOTE: LLVM_USE_SANITIZER checks for a UNIX like system instead of MSVC.
|
|
|
|
|
# But we don't have LLVM_ON_UNIX so checking for MSVC is the best we can do.
|
2018-11-14 07:08:31 +08:00
|
|
|
if (USE_SANITIZER AND NOT MSVC)
|
|
|
|
|
append_flags_if_supported(SANITIZER_FLAGS "-fno-omit-frame-pointer")
|
|
|
|
|
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
|
2015-07-31 06:30:34 +08:00
|
|
|
|
2015-07-30 07:46:55 +08:00
|
|
|
if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND
|
2018-11-14 07:08:31 +08:00
|
|
|
NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO")
|
|
|
|
|
append_flags_if_supported(SANITIZER_FLAGS "-gline-tables-only")
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
2018-11-14 07:08:31 +08:00
|
|
|
if (USE_SANITIZER STREQUAL "Address")
|
|
|
|
|
append_flags(SANITIZER_FLAGS "-fsanitize=address")
|
|
|
|
|
elseif (USE_SANITIZER MATCHES "Memory(WithOrigins)?")
|
|
|
|
|
append_flags(SANITIZER_FLAGS -fsanitize=memory)
|
|
|
|
|
if (USE_SANITIZER STREQUAL "MemoryWithOrigins")
|
|
|
|
|
append_flags(SANITIZER_FLAGS "-fsanitize-memory-track-origins")
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
2018-11-14 07:08:31 +08:00
|
|
|
elseif (USE_SANITIZER STREQUAL "Undefined")
|
|
|
|
|
append_flags(SANITIZER_FLAGS "-fsanitize=undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all")
|
libcxx 'LLVM_USE_SANITIZER=Address;Undefined'
Summary:
Allow users to simultaneously enable address and undefined behavior
sanitizers, in the same manner that LLVM's 'HandleLLVMOptions.cmake'
allows.
Prior to this patch, `cmake -DLLVM_USE_SANITIZER="Address;Undefined"`
would succeed and the build would build most of the LLVM project with
`-fsanitize=address,undefined`, but a warning would be printed by
libcxx's CMake, and the build would use neither sanitizer. This
patch results in no warning being printed, and both sanitizers are used
in building libcxx.
Reviewers: jroelofs, EricWF, ldionne, #libc!
Subscribers: mgorny, dexonsmith, llvm-commits, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77466
2020-04-05 01:01:32 +08:00
|
|
|
elseif (USE_SANITIZER STREQUAL "Address;Undefined" OR
|
|
|
|
|
USE_SANITIZER STREQUAL "Undefined;Address")
|
|
|
|
|
append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all")
|
2018-11-14 07:08:31 +08:00
|
|
|
elseif (USE_SANITIZER STREQUAL "Thread")
|
|
|
|
|
append_flags(SANITIZER_FLAGS -fsanitize=thread)
|
2020-04-18 01:15:58 +08:00
|
|
|
elseif (USE_SANITIZER STREQUAL "DataFlow")
|
|
|
|
|
append_flags(SANITIZER_FLAGS -fsanitize=dataflow)
|
2015-07-30 07:46:55 +08:00
|
|
|
else()
|
2018-11-14 07:08:31 +08:00
|
|
|
message(WARNING "Unsupported value of LLVM_USE_SANITIZER: ${USE_SANITIZER}")
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
2018-11-14 07:08:31 +08:00
|
|
|
elseif(USE_SANITIZER AND MSVC)
|
2015-07-31 06:30:34 +08:00
|
|
|
message(WARNING "LLVM_USE_SANITIZER is not supported on this platform.")
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
2018-11-14 07:08:31 +08:00
|
|
|
set(${OUT_VAR} "${SANITIZER_FLAGS}" PARENT_SCOPE)
|
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
|
|
# Configure for sanitizers. If LIBCXX_STANDALONE_BUILD then we have to do
|
|
|
|
|
# the flag translation ourselves. Othewise LLVM's CMakeList.txt will handle it.
|
|
|
|
|
if (LIBCXX_STANDALONE_BUILD)
|
|
|
|
|
set(LLVM_USE_SANITIZER "" CACHE STRING
|
|
|
|
|
"Define the sanitizer used to build the library and tests")
|
|
|
|
|
endif()
|
|
|
|
|
get_sanitizer_flags(SANITIZER_FLAGS "${LLVM_USE_SANITIZER}")
|
|
|
|
|
if (LIBCXX_STANDALONE_BUILD AND SANITIZER_FLAGS)
|
|
|
|
|
add_flags(${SANITIZER_FLAGS})
|
2015-07-30 07:46:55 +08:00
|
|
|
endif()
|
[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
|
2019-10-09 00:26:24 +08:00
|
|
|
# Link system libraries =======================================================
|
|
|
|
|
function(cxx_link_system_libraries target)
|
2021-02-17 02:02:22 +08:00
|
|
|
|
|
|
|
|
# In order to remove just libc++ from the link step
|
|
|
|
|
# we need to use -nostdlib++ whenever it is supported.
|
|
|
|
|
# Unfortunately this cannot be used universally because for example g++ supports
|
|
|
|
|
# only -nodefaultlibs in which case all libraries will be removed and
|
|
|
|
|
# all libraries but c++ have to be added in manually.
|
|
|
|
|
if (LIBCXX_SUPPORTS_NOSTDLIBXX_FLAG)
|
|
|
|
|
target_add_link_flags_if_supported(${target} PRIVATE "-nostdlib++")
|
|
|
|
|
else()
|
|
|
|
|
target_add_link_flags_if_supported(${target} PRIVATE "-nodefaultlibs")
|
|
|
|
|
target_add_compile_flags_if_supported(${target} PRIVATE "/Zl")
|
|
|
|
|
target_add_link_flags_if_supported(${target} PRIVATE "/nodefaultlib")
|
|
|
|
|
endif()
|
2019-10-09 00:26:24 +08:00
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_SYSTEM_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE System)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_PTHREAD_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE pthread)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_C_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE c)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_M_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE m)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_HAS_RT_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE rt)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_USE_COMPILER_RT)
|
|
|
|
|
find_compiler_rt_library(builtins LIBCXX_BUILTINS_LIBRARY)
|
|
|
|
|
if (LIBCXX_BUILTINS_LIBRARY)
|
|
|
|
|
target_link_libraries(${target} PRIVATE "${LIBCXX_BUILTINS_LIBRARY}")
|
|
|
|
|
endif()
|
2020-04-24 12:19:11 +08:00
|
|
|
elseif (LIBCXX_HAS_GCC_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE gcc)
|
2019-10-09 00:26:24 +08:00
|
|
|
elseif (LIBCXX_HAS_GCC_S_LIB)
|
|
|
|
|
target_link_libraries(${target} PRIVATE gcc_s)
|
|
|
|
|
endif()
|
|
|
|
|
|
[libc++] Link against libatomic when it is found
Before this patch, we tried detecting whether small atomics were available
without linking against libatomic. However, that's not really what we want
to know -- instead, we want to know what's required in order to support
atomics fully, which is to link against libatomic when it's provided.
That is both much simpler, and it doesn't suffer the problem that we would
not link against libatomic when small atomics didn't require it, which
lead to non-lockfree atomics never working.
Furthermore, because we understand that some platforms might not want to
(or be able to) ship non-lockfree atomics, we add that notion to the test
suite, independently of a potential extern library.
After this patch, we therefore:
(1) Link against libatomic when it is provided
(2) Independently detect whether non-lockfree atomics are supported in
the test suite, regardless of whether that means we're linking against
an external library or not (which is an implementation detail).
Differential Revision: https://reviews.llvm.org/D81190
2020-06-05 02:54:38 +08:00
|
|
|
if (LIBCXX_HAS_ATOMIC_LIB)
|
2019-10-09 00:26:24 +08:00
|
|
|
target_link_libraries(${target} PRIVATE atomic)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (MINGW)
|
|
|
|
|
target_link_libraries(${target} PRIVATE "${MINGW_LIBRARIES}")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_TARGETING_MSVC)
|
|
|
|
|
if (LIBCXX_DEBUG_BUILD)
|
|
|
|
|
set(LIB_SUFFIX "d")
|
|
|
|
|
else()
|
|
|
|
|
set(LIB_SUFFIX "")
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
target_link_libraries(${target} PRIVATE ucrt${LIB_SUFFIX}) # Universal C runtime
|
|
|
|
|
target_link_libraries(${target} PRIVATE vcruntime${LIB_SUFFIX}) # C++ runtime
|
|
|
|
|
target_link_libraries(${target} PRIVATE msvcrt${LIB_SUFFIX}) # C runtime startup files
|
|
|
|
|
target_link_libraries(${target} PRIVATE msvcprt${LIB_SUFFIX}) # C++ standard library. Required for exception_ptr internals.
|
|
|
|
|
# Required for standards-complaint wide character formatting functions
|
|
|
|
|
# (e.g. `printfw`/`scanfw`)
|
|
|
|
|
target_link_libraries(${target} PRIVATE iso_stdio_wide_specifiers)
|
|
|
|
|
endif()
|
2020-01-28 09:29:41 +08:00
|
|
|
|
|
|
|
|
if (ANDROID AND ANDROID_PLATFORM_LEVEL LESS 21)
|
|
|
|
|
target_link_libraries(${target} PUBLIC android_support)
|
|
|
|
|
endif()
|
2019-10-09 00:26:24 +08:00
|
|
|
endfunction()
|
|
|
|
|
|
2019-10-03 04:07:01 +08:00
|
|
|
# Windows-related flags =======================================================
|
|
|
|
|
function(cxx_add_windows_flags target)
|
|
|
|
|
if(WIN32 AND NOT MINGW)
|
|
|
|
|
target_compile_definitions(${target} PRIVATE
|
|
|
|
|
# Ignore the -MSC_VER mismatch, as we may build
|
|
|
|
|
# with a different compatibility version.
|
|
|
|
|
_ALLOW_MSC_VER_MISMATCH
|
|
|
|
|
# Don't check the msvcprt iterator debug levels
|
|
|
|
|
# as we will define the iterator types; libc++
|
|
|
|
|
# uses a different macro to identify the debug
|
|
|
|
|
# level.
|
|
|
|
|
_ALLOW_ITERATOR_DEBUG_LEVEL_MISMATCH
|
|
|
|
|
# We are building the c++ runtime, don't pull in
|
|
|
|
|
# msvcprt.
|
|
|
|
|
_CRTBLD
|
|
|
|
|
# Don't warn on the use of "deprecated"
|
|
|
|
|
# "insecure" functions which are standards
|
|
|
|
|
# specified.
|
|
|
|
|
_CRT_SECURE_NO_WARNINGS
|
|
|
|
|
# Use the ISO conforming behaviour for conversion
|
|
|
|
|
# in printf, scanf.
|
|
|
|
|
_CRT_STDIO_ISO_WIDE_SPECIFIERS)
|
|
|
|
|
endif()
|
|
|
|
|
endfunction()
|
|
|
|
|
|
[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
# Configuration file flags =====================================================
|
2018-09-26 16:24:51 +08:00
|
|
|
if (NOT LIBCXX_ABI_VERSION EQUAL 1)
|
2015-10-14 07:48:28 +08:00
|
|
|
config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
|
|
|
|
|
endif()
|
2018-10-31 05:44:53 +08:00
|
|
|
if (NOT LIBCXX_ABI_NAMESPACE STREQUAL "")
|
|
|
|
|
if (NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*")
|
[libc++] Force the ABI namespace to be a reserved identifier
Summary:
When the ABI namespace isn't a reserved identifier, we were issuing a
warning, but this should have been an error since the beginning. This
commit enforces that the ABI namespace is a reserved identifier, and
changes the ABI namespace used by LibFuzzer.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, #sanitizers, libcxx-commits, llvm-commits
Tags: #sanitizers, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D69408
2019-10-25 05:16:37 +08:00
|
|
|
message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier.")
|
2018-10-31 05:44:53 +08:00
|
|
|
endif()
|
|
|
|
|
if (LIBCXX_ABI_NAMESPACE MATCHES "__[0-9]+$")
|
|
|
|
|
message(FATAL_ERROR "LIBCXX_ABI_NAMESPACE '${LIBCXX_ABI_NAMESPACE}' is reserved for use by libc++.")
|
|
|
|
|
endif()
|
|
|
|
|
config_define(${LIBCXX_ABI_NAMESPACE} _LIBCPP_ABI_NAMESPACE)
|
|
|
|
|
endif()
|
2015-10-14 07:48:28 +08:00
|
|
|
config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
|
2017-10-05 10:18:08 +08:00
|
|
|
config_define_if(LIBCXX_ABI_FORCE_ITANIUM _LIBCPP_ABI_FORCE_ITANIUM)
|
|
|
|
|
config_define_if(LIBCXX_ABI_FORCE_MICROSOFT _LIBCPP_ABI_FORCE_MICROSOFT)
|
[libcxx] By default, do not use internal_linkage to hide symbols from the ABI
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
2018-08-16 20:44:28 +08:00
|
|
|
config_define_if(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT)
|
[libcxx] Capture configuration information when installing the libc++ headers
Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
2015-10-14 06:12:02 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_THREADS _LIBCPP_HAS_NO_THREADS)
|
|
|
|
|
config_define_if_not(LIBCXX_ENABLE_MONOTONIC_CLOCK _LIBCPP_HAS_NO_MONOTONIC_CLOCK)
|
2020-11-17 07:13:43 +08:00
|
|
|
if (NOT LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION STREQUAL "default")
|
2020-05-16 03:58:19 +08:00
|
|
|
config_define("${LIBCXX_TYPEINFO_COMPARISON_IMPLEMENTATION}" _LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION)
|
2019-05-29 10:21:37 +08:00
|
|
|
endif()
|
2016-05-26 01:40:09 +08:00
|
|
|
config_define_if(LIBCXX_HAS_PTHREAD_API _LIBCPP_HAS_THREAD_API_PTHREAD)
|
[libcxx] Introduce an externally-threaded libc++ variant.
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
2016-09-12 05:46:40 +08:00
|
|
|
config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
|
2018-01-06 04:48:29 +08:00
|
|
|
config_define_if(LIBCXX_HAS_WIN32_THREAD_API _LIBCPP_HAS_THREAD_API_WIN32)
|
2017-01-07 04:05:40 +08:00
|
|
|
config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
|
2015-11-09 18:21:04 +08:00
|
|
|
config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
|
2017-10-10 03:25:17 +08:00
|
|
|
config_define_if(LIBCXX_NO_VCRUNTIME _LIBCPP_NO_VCRUNTIME)
|
2019-08-06 02:29:14 +08:00
|
|
|
config_define_if(LIBCXX_ENABLE_PARALLEL_ALGORITHMS _LIBCPP_HAS_PARALLEL_ALGORITHMS)
|
2021-01-19 01:18:18 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_FILESYSTEM _LIBCPP_HAS_NO_FILESYSTEM_LIBRARY)
|
2020-10-15 22:32:09 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_RANDOM_DEVICE _LIBCPP_HAS_NO_RANDOM_DEVICE)
|
2020-10-10 03:31:05 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_LOCALIZATION _LIBCPP_HAS_NO_LOCALIZATION)
|
2021-05-26 02:11:08 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_UNICODE _LIBCPP_HAS_NO_UNICODE)
|
2020-11-05 04:01:25 +08:00
|
|
|
config_define_if_not(LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS)
|
2021-07-25 15:18:53 +08:00
|
|
|
# Incomplete features get their own specific disabling flags. This makes it
|
|
|
|
|
# easier to grep for target specific flags once the feature is complete.
|
|
|
|
|
config_define_if_not(LIBCXX_ENABLE_INCOMPLETE_FEATURES _LIBCPP_HAS_NO_INCOMPLETE_FORMAT)
|
|
|
|
|
config_define_if_not(LIBCXX_ENABLE_INCOMPLETE_FEATURES _LIBCPP_HAS_NO_INCOMPLETE_RANGES)
|
2015-11-09 18:21:04 +08:00
|
|
|
|
2017-10-05 07:17:12 +08:00
|
|
|
if (LIBCXX_ABI_DEFINES)
|
|
|
|
|
set(abi_defines)
|
|
|
|
|
foreach (abi_define ${LIBCXX_ABI_DEFINES})
|
|
|
|
|
if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
|
|
|
|
|
message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
|
|
|
|
|
endif()
|
|
|
|
|
list(APPEND abi_defines "#define ${abi_define}")
|
|
|
|
|
endforeach()
|
|
|
|
|
string(REPLACE ";" "\n" abi_defines "${abi_defines}")
|
|
|
|
|
config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
|
|
|
|
|
endif()
|
|
|
|
|
|
2016-09-27 06:19:41 +08:00
|
|
|
# By default libc++ on Windows expects to use a shared library, which requires
|
|
|
|
|
# the headers to use DLL import/export semantics. However when building a
|
|
|
|
|
# static library only we modify the headers to disable DLL import/export.
|
|
|
|
|
if (DEFINED WIN32 AND LIBCXX_ENABLE_STATIC AND NOT LIBCXX_ENABLE_SHARED)
|
|
|
|
|
message(STATUS "Generating custom __config for non-DLL Windows build")
|
2016-12-06 03:40:12 +08:00
|
|
|
config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
|
2016-09-27 06:19:41 +08:00
|
|
|
endif()
|
|
|
|
|
|
2020-10-23 15:54:02 +08:00
|
|
|
if (WIN32 AND LIBCXX_ENABLE_STATIC_ABI_LIBRARY)
|
|
|
|
|
# If linking libcxxabi statically into libcxx, skip the dllimport attributes
|
|
|
|
|
# on symbols we refer to from libcxxabi.
|
|
|
|
|
add_definitions(-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS)
|
|
|
|
|
endif()
|
|
|
|
|
|
2019-10-05 06:50:23 +08:00
|
|
|
# Setup all common build flags =================================================
|
|
|
|
|
function(cxx_add_common_build_flags target)
|
|
|
|
|
cxx_add_basic_build_flags(${target})
|
|
|
|
|
cxx_add_warning_flags(${target})
|
|
|
|
|
cxx_add_windows_flags(${target})
|
|
|
|
|
cxx_add_exception_flags(${target})
|
|
|
|
|
cxx_add_rtti_flags(${target})
|
|
|
|
|
cxx_add_module_flags(${target})
|
2019-10-09 00:26:24 +08:00
|
|
|
cxx_link_system_libraries(${target})
|
2019-10-05 06:50:23 +08:00
|
|
|
endfunction()
|
|
|
|
|
|
2010-12-11 03:47:54 +08:00
|
|
|
#===============================================================================
|
2015-07-31 06:30:34 +08:00
|
|
|
# Setup Source Code And Tests
|
2010-12-11 03:47:54 +08:00
|
|
|
#===============================================================================
|
2013-11-16 01:18:57 +08:00
|
|
|
add_subdirectory(include)
|
2019-05-01 14:40:36 +08:00
|
|
|
add_subdirectory(src)
|
2021-07-15 22:19:39 +08:00
|
|
|
add_subdirectory(utils)
|
2015-08-23 03:40:49 +08:00
|
|
|
|
2018-11-15 04:38:46 +08:00
|
|
|
set(LIBCXX_TEST_DEPS "")
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY)
|
|
|
|
|
list(APPEND LIBCXX_TEST_DEPS cxx_experimental)
|
|
|
|
|
endif()
|
|
|
|
|
|
|
|
|
|
if (LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY)
|
|
|
|
|
list(APPEND LIBCXX_TEST_DEPS cxx_external_threads)
|
|
|
|
|
endif()
|
2016-11-14 10:43:12 +08:00
|
|
|
|
[libcxx] Add support for benchmark tests using Google Benchmark.
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
2016-07-20 07:07:03 +08:00
|
|
|
if (LIBCXX_INCLUDE_BENCHMARKS)
|
|
|
|
|
add_subdirectory(benchmarks)
|
|
|
|
|
endif()
|
2017-03-02 05:53:30 +08:00
|
|
|
|
2015-07-31 06:30:34 +08:00
|
|
|
if (LIBCXX_INCLUDE_TESTS)
|
2020-06-29 23:51:15 +08:00
|
|
|
add_subdirectory(test)
|
2016-11-14 10:43:12 +08:00
|
|
|
add_subdirectory(lib/abi)
|
2020-06-29 23:51:15 +08:00
|
|
|
if (LIBCXX_STANDALONE_BUILD)
|
|
|
|
|
include(AddLLVM) # for get_llvm_lit_path
|
|
|
|
|
# Make sure the llvm-lit script is generated into the bin directory, and
|
|
|
|
|
# do it after adding all tests, since the generated script will only work
|
|
|
|
|
# correctly discovered tests against test locations from the source tree
|
|
|
|
|
# that have already been discovered.
|
|
|
|
|
add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/llvm-lit)
|
|
|
|
|
endif()
|
2017-09-20 01:19:10 +08:00
|
|
|
endif()
|
|
|
|
|
|
2015-08-23 03:40:49 +08:00
|
|
|
if (LIBCXX_INCLUDE_DOCS)
|
|
|
|
|
add_subdirectory(docs)
|
|
|
|
|
endif()
|