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
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
2022-01-01 15:03:31 +08:00
set ( LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake" )
2010-12-11 03:47:54 +08:00
# Add path for custom modules
2022-01-01 15:03:31 +08:00
list ( INSERT CMAKE_MODULE_PATH 0
2010-12-11 03:47:54 +08:00
" $ { C M A K E _ C U R R E N T _ S O U R C E _ D I R } / c m a k e "
" $ { C M A K E _ C U R R E N T _ S O U R C E _ D I R } / c m a k e / M o d u l e s "
2022-01-01 15:03:31 +08:00
" $ { L L V M _ C O M M O N _ C M A K E _ U T I L S } "
" $ { L L V M _ C O M M O N _ C M A K E _ U T I L S } / M o d u l e s "
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" )
2022-01-19 14:45:07 +08:00
include ( GNUInstallDirs )
2020-08-24 17:01:05 +08:00
2016-02-08 11:50:18 +08:00
# Require out of source build.
include ( MacroEnsureOutOfSourceBuild )
MACRO_ENSURE_OUT_OF_SOURCE_BUILD (
" $ { P R O J E C T _ N A M E } r e q u i r e s a n o u t o f s o u r c e b u i l d . P l e a s e c r e a t e a s e p a r a t e
b u i l d d i r e c t o r y a n d r u n ' c m a k e / p a t h / t o / $ { P R O J E C T _ N A M E } [ o p t i o n s ] ' t h e r e . "
)
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 ---------------------------------------------------------------
[libc++] Add a lightweight overridable assertion handler
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
2022-03-04 06:37:03 +08:00
option ( LIBCXX_ENABLE_ASSERTIONS
" E n a b l e a s s e r t i o n s i n s i d e t h e c o m p i l e d l i b r a r y , a n d a t t h e s a m e t i m e m a k e i t t h e
d e f a u l t w h e n c o m p i l i n g u s e r c o d e . N o t e t h a t a s s e r t i o n s c a n b e e n a b l e d o r d i s a b l e d
b y u s e r s i n t h e i r o w n c o d e r e g a r d l e s s o f t h i s o p t i o n . " O F F )
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 )
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"
$ { E N A B L E _ F I L E S Y S T E M _ D E F A U L T } )
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 )
[libc++] Make the Debug mode a configuration-time only option
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
2022-04-02 04:38:30 +08:00
option ( LIBCXX_ENABLE_DEBUG_MODE
" W h e t h e r t o b u i l d l i b c + + w i t h t h e d e b u g m o d e e n a b l e d .
B y d e f a u l t , t h i s i s t u r n e d o f f . T u r n i n g i t o n r e s u l t s i n a d i f f e r e n t ABI ( additional
s y m b o l s b u t a l s o p o t e n t i a l l y d i f f e r e n t l a y o u t s o f t y p e s ) , a n d o n e s h o u l d n o t m i x c o d e
b u i l t a g a i n s t a d y l i b t h a t h a s d e b u g m o d e a n d c o d e b u i l t a g a i n s t a r e g u l a r d y l i b . " O F F )
2020-10-15 22:32:09 +08:00
option ( LIBCXX_ENABLE_RANDOM_DEVICE
" W h e t h e r t o i n c l u d e s u p p o r t f o r s t d : : r a n d o m _ d e v i c e i n t h e l i b r a r y . D i s a b l i n g
t h i s c a n b e u s e f u l w h e n b u i l d i n g t h e l i b r a r y f o r p l a t f o r m s t h a t d o n ' t h a v e
a s o u r c e o f r a n d o m n e s s , s u c h a s s o m e e m b e d d e d p l a t f o r m s . W h e n t h i s i s n o t
s u p p o r t e d , m o s t o f < r a n d o m > w i l l s t i l l b e a v a i l a b l e , b u t s t d : : r a n d o m _ d e v i c e
w i l l n o t . " O N )
2020-10-10 03:31:05 +08:00
option ( LIBCXX_ENABLE_LOCALIZATION
" W h e t h e r t o i n c l u d e s u p p o r t f o r l o c a l i z a t i o n i n t h e l i b r a r y . D i s a b l i n g
l o c a l i z a t i o n c a n b e u s e f u l w h e n p o r t i n g t o p l a t f o r m s t h a t d o n ' t s u p p o r t
t h e C l o c a l e API ( e.g. embedded ) . W h e n l o c a l i z a t i o n i s n o t s u p p o r t e d ,
s e v e r a l p a r t s o f t h e l i b r a r y w i l l b e d i s a b l e d : < i o s t r e a m > , < r e g e x > , < l o c a l e >
w i l l b e c o m p l e t e l y u n u s a b l e , a n d o t h e r p a r t s m a y b e o n l y p a r t l y a v a i l a b l e . " O N )
2021-05-26 02:11:08 +08:00
option ( LIBCXX_ENABLE_UNICODE
" W h e t h e r t o i n c l u d e s u p p o r t f o r U n i c o d e i n t h e l i b r a r y . D i s a b l i n g U n i c o d e c a n
2021-09-09 23:14:33 +08:00
b e u s e f u l w h e n p o r t i n g t o p l a t f o r m s t h a t d o n ' t s u p p o r t U T F - 8 encoding ( e.g.
e m b e d d e d ) . " O N )
2021-08-24 03:32:36 +08:00
option ( LIBCXX_ENABLE_WIDE_CHARACTERS
" W h e t h e r t o i n c l u d e s u p p o r t f o r w i d e c h a r a c t e r s i n t h e l i b r a r y . D i s a b l i n g
w i d e c h a r a c t e r s u p p o r t c a n b e u s e f u l w h e n p o r t i n g t o p l a t f o r m s t h a t d o n ' t
s u p p o r t t h e C f u n c t i o n a l i t y f o r w i d e c h a r a c t e r s . W h e n w i d e c h a r a c t e r s a r e
n o t s u p p o r t e d , s e v e r a l p a r t s o f t h e l i b r a r y w i l l b e d i s a b l e d , n o t a b l y t h e
w i d e c h a r a c t e r s p e c i a l i z a t i o n s o f s t d : : b a s i c _ s t r i n g . " O N )
2020-11-05 04:01:25 +08:00
option ( LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS
" W h e t h e r t o t u r n o n v e n d o r a v a i l a b i l i t y a n n o t a t i o n s o n d e c l a r a t i o n s t h a t d e p e n d
o n d e f i n i t i o n s i n a s h a r e d l i b r a r y . B y d e f a u l t , w e a s s u m e t h a t w e ' r e n o t b u i l d i n g
l i b c + + f o r a n y s p e c i f i c v e n d o r , a n d w e d i s a b l e t h o s e a n n o t a t i o n s . V e n d o r s w i s h i n g
t o p r o v i d e c o m p i l e - t i m e e r r o r s w h e n u s i n g f e a t u r e s u n a v a i l a b l e o n s o m e v e r s i o n o f
t h e s h a r e d l i b r a r y t h e y s h i p p e d s h o u l d t u r n t h i s o n a n d s e e ` i n c l u d e / _ _ a v a i l a b i l i t y `
f o r m o r e d e t a i l s . " O F F )
2022-03-15 02:23:38 +08:00
if ( CMAKE_CXX_COMPILER_ID STREQUAL "GNU" )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-shared-gcc.cfg.in" )
elseif ( MINGW )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-mingw.cfg.in" )
elseif ( WIN32 ) # clang-cl
if ( LIBCXX_ENABLE_SHARED )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-shared-clangcl.cfg.in" )
else ( )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-static-clangcl.cfg.in" )
endif ( )
else ( )
if ( LIBCXX_ENABLE_SHARED )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-shared.cfg.in" )
else ( )
set ( LIBCXX_DEFAULT_TEST_CONFIG "llvm-libc++-static.cfg.in" )
endif ( )
endif ( )
set ( LIBCXX_TEST_CONFIG "${LIBCXX_DEFAULT_TEST_CONFIG}" CACHE STRING
2021-09-30 03:26:05 +08:00
" T h e p a t h t o t h e L i t t e s t i n g c o n f i g u r a t i o n t o u s e w h e n r u n n i n g t h e t e s t s .
I f a r e l a t i v e p a t h i s p r o v i d e d , i t i s a s s u m e d t o b e r e l a t i v e t o ' < m o n o r e p o > / l i b c x x / t e s t / c o n f i g s ' . " )
if ( NOT IS_ABSOLUTE "${LIBCXX_TEST_CONFIG}" )
set ( LIBCXX_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/configs/${LIBCXX_TEST_CONFIG}" )
endif ( )
2022-03-15 02:23:38 +08:00
message ( STATUS "Using libc++ testing configuration: ${LIBCXX_TEST_CONFIG}" )
2020-07-09 23:54:09 +08:00
set ( LIBCXX_TEST_PARAMS "" CACHE STRING
" A l i s t o f p a r a m e t e r s t o r u n t h e L i t t e s t s u i t e w i t h . " )
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
" A r g u m e n t s t o p a s s w h e n r u n n i n g t h e b e n c h m a r k s u s i n g c h e c k - c x x - b e n c h m a r k s " )
2016-10-31 06:53:00 +08:00
set ( LIBCXX_BENCHMARK_NATIVE_STDLIB "" CACHE STRING
" B u i l d t h e b e n c h m a r k s a g a i n s t t h e s p e c i f i e d n a t i v e S T L .
T h e v a l u e m u s t b e o n e o f l i b c + + / l i b s t d c + + " )
set ( LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN "" CACHE STRING
" U s e a l t e r n a t e G C C t o o l c h a i n w h e n b u i l d i n g t h e n a t i v e b e n c h m a r k s " )
if ( LIBCXX_BENCHMARK_NATIVE_STDLIB )
if ( NOT ( LIBCXX_BENCHMARK_NATIVE_STDLIB STREQUAL "libc++"
O R L I B C X X _ B E N C H M A R K _ N A T I V E _ S T D L I B S T R E Q U A L " l i b s t d c + + " ) )
message ( FATAL_ERROR "Invalid value for LIBCXX_BENCHMARK_NATIVE_STDLIB: "
" ' $ { L I B C X X _ B E N C H M A R K _ N A T I V E _ S T D L I B } ' " )
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
" D e f i n e s u f f i x o f l i b r a r y d i r e c t o r y 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
" I n s t a l l t h e s t a t i c l i b c + + l i b r a r y . " O N
" L I B C X X _ E N A B L E _ S T A T I C ; L I B C X X _ I N S T A L L _ L I B R A R Y " O F F )
cmake_dependent_option ( LIBCXX_INSTALL_SHARED_LIBRARY
" I n s t a l l t h e s h a r e d l i b c + + l i b r a r y . " O N
" L I B C X X _ E N A B L E _ S H A R E D ; L I B C X X _ I N S T A L L _ L I B R A R Y " O F F )
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
2022-02-08 03:52:17 +08:00
option ( LIBCXX_ABI_UNSTABLE "Use the unstable ABI of libc++. This is equivalent to specifying LIBCXX_ABI_VERSION=n, where n is the not-yet-stable version." OFF )
if ( LIBCXX_ABI_UNSTABLE )
set ( abi_version "2" )
else ( )
set ( abi_version "1" )
endif ( )
2022-05-16 21:50:56 +08:00
set ( LIBCXX_ABI_VERSION "${abi_version}" CACHE STRING
" A B I v e r s i o n o f l i b c + + . C a n b e e i t h e r 1 o r 2 , w h e r e 2 i s c u r r e n t l y t h e u n s t a b l e A B I .
D e f a u l t s t o 1 u n l e s s L I B C X X _ A B I _ U N S T A B L E i s s p e c i f i e d , i n w h i c h c a s e t h i s i s 2 . " )
set ( LIBCXX_LIBRARY_VERSION "${LIBCXX_ABI_VERSION}.0" CACHE STRING
" V e r s i o n o f l i b c + + . T h i s w i l l b e r e f l e c t e d i n t h e n a m e o f t h e s h a r e d l i b r a r y p r o d u c e d .
F o r e x a m p l e , - D L I B C X X _ L I B R A R Y _ V E R S I O N = x . y w i l l r e s u l t i n t h e l i b r a r y b e i n g n a m e d
l i b c + + . x . y . d y l i b , a l o n g w i t h t h e u s u a l s y m l i n k s p o i n t i n g t o t h a t . O n A p p l e p l a t f o r m s ,
t h i s a l s o c o n t r o l s t h e l i n k e r ' s ' c u r r e n t _ v e r s i o n ' p r o p e r t y . " )
2022-02-08 03:52:17 +08:00
set ( LIBCXX_ABI_NAMESPACE "__${LIBCXX_ABI_VERSION}" CACHE STRING "The inline ABI namespace used by libc++. It defaults to __n where `n` is the current ABI version." )
if ( NOT LIBCXX_ABI_NAMESPACE MATCHES "__.*" )
2022-06-09 23:49:03 +08:00
message ( FATAL_ERROR "LIBCXX_ABI_NAMESPACE must be a reserved identifier, got '${LIBCXX_ABI_NAMESPACE}'." )
2022-02-08 03:52:17 +08:00
endif ( )
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
" O v e r r i d e t h e i m p l e m e n t a t i o n t o u s e f o r c o m p a r i n g t y p e i n f o s . B y d e f a u l t , t h i s
i s d e t e c t e d a u t o m a t i c a l l y b y t h e l i b r a r y , b u t t h i s o p t i o n a l l o w s o v e r r i d i n g
w h i c h i m p l e m e n t a t i o n i s u s e d u n c o n d i t i o n a l l y .
S e e t h e d o c u m e n t a t i o n i n < l i b c x x / i n c l u d e / t y p e i n f o > f o r d e t a i l s o n w h a t e a c h
v a l u e m e a n s . " )
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
L I B C X X _ T Y P E I N F O _ C O M P A R I S O N _ I M P L E M E N T A T I O N " )
2019-05-29 10:21:37 +08:00
endif ( )
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." )
2021-12-21 07:19:34 +08:00
option ( LIBCXX_EXTRA_SITE_DEFINES "Extra defines to add into __config_site" )
2016-08-24 12:22:52 +08:00
option ( LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF )
2015-07-31 06:30:34 +08:00
2022-07-19 23:04:31 +08:00
option ( LIBCXX_ENABLE_BACKWARDS_COMPATIBILITY_DEBUG_MODE_SYMBOLS
[libc++] Make the Debug mode a configuration-time only option
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
2022-04-02 04:38:30 +08:00
" W h e t h e r t o i n c l u d e t h e o l d D e b u g m o d e s y m b o l s i n t h e c o m p i l e d l i b r a r y . T h i s
i s p r o v i d e d f o r b a c k w a r d s c o m p a t i b i l i t y s i n c e t h e c o m p i l e d l i b r a r y u s e d t o
a l w a y s c o n t a i n t h o s e s y m b o l s , r e g a r d l e s s o f w h e t h e r t h e l i b r a r y w a s b u i l t
2022-07-19 23:04:31 +08:00
w i t h t h e d e b u g m o d e e n a b l e d . T h i s i s O F F b y d e f a u l t , p l e a s e c o n t a c t t h e l i b c + +
d e v e l o p e r s i f y o u n e e d t o t u r n t h i s o n , a s t h i s w i l l b e r e m o v e d i n L L V M 1 6 . " O F F )
[libc++] Make the Debug mode a configuration-time only option
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
2022-04-02 04:38:30 +08:00
2015-07-31 06:30:34 +08:00
# ABI Library options ---------------------------------------------------------
2022-03-01 21:42:13 +08:00
if ( LIBCXX_TARGETING_MSVC )
set ( LIBCXX_DEFAULT_ABI_LIBRARY "vcruntime" )
elseif ( ${ CMAKE_SYSTEM_NAME } MATCHES "FreeBSD" )
set ( LIBCXX_DEFAULT_ABI_LIBRARY "libcxxrt" )
else ( )
set ( LIBCXX_DEFAULT_ABI_LIBRARY "libcxxabi" )
endif ( )
2015-07-31 06:30:34 +08:00
2022-03-01 21:42:13 +08:00
set ( LIBCXX_SUPPORTED_ABI_LIBRARIES none libcxxabi system-libcxxabi libcxxrt libstdc++ libsupc++ vcruntime )
set ( LIBCXX_CXX_ABI "${LIBCXX_DEFAULT_ABI_LIBRARY}" CACHE STRING "Specify C++ ABI library to use. Supported values are ${LIBCXX_SUPPORTED_ABI_LIBRARIES}." )
if ( NOT "${LIBCXX_CXX_ABI}" IN_LIST LIBCXX_SUPPORTED_ABI_LIBRARIES )
message ( FATAL_ERROR "Unsupported C++ ABI library: '${LIBCXX_CXX_ABI}'. Supported values are ${LIBCXX_SUPPORTED_ABI_LIBRARIES}." )
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
" U s e a s t a t i c c o p y o f t h e A B I l i b r a r y w h e n l i n k i n g l i b c + + .
T h i s o p t i o n c a n n o t b e u s e d w i t h L I B C X X _ E N A B L E _ A B I _ L I N K E R _ S C R I P T . " O F F )
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
" S t a t i c a l l y l i n k t h e A B I l i b r a r y t o s t a t i c l i b r a r y " O N
2022-05-19 00:05:45 +08:00
" L I B C X X _ E N A B L E _ S T A T I C _ A B I _ L I B R A R Y " O F F )
2018-07-24 15:06:17 +08:00
cmake_dependent_option ( LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY
" S t a t i c a l l y l i n k t h e A B I l i b r a r y t o s h a r e d l i b r a r y " O N
2022-05-19 00:05:45 +08:00
" L I B C X X _ E N A B L E _ S T A T I C _ A B I _ L I B R A R Y " O F F )
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
2022-03-01 21:42:13 +08:00
A N D N O T L I B C X X _ C X X _ A B I S T R E Q U A L " n o n e "
2020-04-29 09:37:28 +08:00
A N D P y t h o n 3 _ E X E C U T A B L E
2016-05-15 07:58:11 +08:00
A N D L I B C X X _ E N A B L E _ S H A R E D )
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
" U s e a n d i n s t a l l a l i n k e r s c r i p t f o r t h e g i v e n A B I l i b r a r y "
2015-10-16 07:04:54 +08:00
$ { E N A B L E _ L I N K E R _ S C R I P T _ D E F A U L T _ V A L U E } )
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
" B u i l d l i b c + + w i t h d e f i n i t i o n s f o r o p e r a t o r n e w / d e l e t e . T h e s e a r e n o r m a l l y
d e f i n e d i n l i b c + + a b i , b u t t h i s o p t i o n c a n b e u s e d t o d e f i n e t h e m i n l i b c + +
i n s t e a d . I f y o u d e f i n e t h e m i n l i b c + + , m a k e s u r e t h e y a r e N O T d e f i n e d i n
l i b c + + a b i . D o i n g o t h e r w i s e i s a n O D R v i o l a t i o n . " O F F )
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 --------------------------------------------------------------
2021-11-24 05:34:09 +08:00
option ( LIBCXX_BUILD_32_BITS "Build 32 bit multilib libc++. This option is not supported anymore when building the runtimes. Please specify a full triple instead." ${ LLVM_BUILD_32_BITS } )
if ( LIBCXX_BUILD_32_BITS )
2021-12-02 01:57:30 +08:00
message ( FATAL_ERROR "LIBCXX_BUILD_32_BITS is not supported anymore when building the runtimes, please specify a full triple instead." )
2021-11-24 05:34:09 +08:00
endif ( )
2021-10-13 03:59:08 +08:00
2021-10-13 03:59:08 +08:00
# TODO: Remove this after branching for LLVM 15
if ( LIBCXX_SYSROOT OR LIBCXX_TARGET_TRIPLE OR LIBCXX_GCC_TOOLCHAIN )
message ( WARNING "LIBCXX_SYSROOT, LIBCXX_TARGET_TRIPLE and LIBCXX_GCC_TOOLCHAIN are not supported anymore, please use the native CMake equivalents instead" )
2022-02-15 21:18:38 +08:00
endif ( )
2022-02-17 00:59:32 +08:00
2015-07-31 06:30:34 +08:00
# 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
" B u i l d l i b c + + w i t h s u p p o r t f o r a m o n o t o n i c c l o c k .
2015-08-25 05:20:07 +08:00
T h i s o p t i o n m a y o n l y b e s e t t o O F F w h e n L I B C X X _ E N A B L E _ T H R E A D S = O F F . " O N )
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
" B u i l d l i b c + + w i t h a n e x t e r n a l i z e d t h r e a d i n g A P I .
T h i s o p t i o n m a y o n l y b e s e t t o O N w h e n L I B C X X _ E N A B L E _ T H R E A D S = O N . " O F F )
2017-01-07 04:05:40 +08:00
option ( LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
" B u i l d l i b c + + w i t h a n e x t e r n a l i z e d t h r e a d i n g l i b r a r y .
T h i s o p t i o n m a y o n l y b e s e t t o O N w h e n L I B C X X _ E N A B L E _ T H R E A D S = O N " O F F )
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
" T h e P r o f i l e - r t l i b r a r y u s e d t o b u i l d w i t h c o d e c o v e r a g e " )
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"
$ { L I B C X X _ C O N F I G U R E _ I D E _ D E F A U L T } )
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)
Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library. If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.
The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.
(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)
This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.
Differential Revision: https://reviews.llvm.org/D125715
2022-04-10 04:40:07 +08:00
set ( LIBCXX_HERMETIC_STATIC_LIBRARY_DEFAULT OFF )
if ( WIN32 )
set ( LIBCXX_HERMETIC_STATIC_LIBRARY_DEFAULT ON )
endif ( )
2019-01-06 14:14:31 +08:00
option ( LIBCXX_HERMETIC_STATIC_LIBRARY
[runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)
Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library. If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.
The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.
(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)
This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.
Differential Revision: https://reviews.llvm.org/D125715
2022-04-10 04:40:07 +08:00
" D o n o t e x p o r t a n y s y m b o l s f r o m t h e s t a t i c l i b r a r y . " $ { L I B C X X _ H E R M E T I C _ S T A T I C _ L I B R A R Y _ D E F A U L T } )
2019-01-06 14:14:31 +08:00
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"
" w h e n L I B C X X _ E N A B L E _ T H R E A D S i s a l s o s e t t o O F F . " )
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"
" w h e n L I B C X X _ E N A B L E _ T H R E A D S i s a l s o s e t t o O N . " )
endif ( )
if ( LIBCXX_HAS_EXTERNAL_THREAD_API )
message ( FATAL_ERROR "LIBCXX_HAS_EXTERNAL_THREAD_API can only be set to ON"
" w h e n L I B C X X _ E N A B L E _ T H R E A D S i s a l s o s e t t o O N . " )
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 "
" t o O N w h e n L I B C X X _ E N A B L E _ T H R E A D S i s a l s o s e t t o O N . " )
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"
" w h e n L I B C X X _ E N A B L E _ T H R E A D S i s a l s o s e t t o O N . " )
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 "
" L I B C X X _ H A S _ E X T E R N A L _ T H R E A D _ A P I c a n n o t b o t h b e O N a t "
" t h e s a m e t i m e " )
endif ( )
if ( LIBCXX_HAS_PTHREAD_API )
message ( FATAL_ERROR "The options LIBCXX_HAS_EXTERNAL_THREAD_API"
" a n d L I B C X X _ H A S _ P T H R E A D _ A P I c a n n o t b e b o t h "
" s e t t o O N a t t h e s a m e t i m e . " )
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"
" a n d L I B C X X _ H A S _ W I N 3 2 _ T H R E A D _ A P I c a n n o t b e b o t h "
" s e t t o O N a t t h e s a m e t i m e . " )
endif ( )
endif ( )
if ( LIBCXX_HAS_PTHREAD_API )
if ( LIBCXX_HAS_WIN32_THREAD_API )
message ( FATAL_ERROR "The options LIBCXX_HAS_PTHREAD_API"
" a n d L I B C X X _ H A S _ W I N 3 2 _ T H R E A D _ A P I c a n n o t b e b o t h "
" s e t t o O N a t t h e s a m e t i m e . " )
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 ( )
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.
L I B C X X _ E N A B L E _ S T A T I C _ A B I _ L I B R A R Y c a n n o t b e s p e c i f i e d w i t h
L I B C X X _ E N A B L E _ A B I _ L I N K E R _ S C R I P T " )
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.
2022-01-11 11:03:21 +08:00
2022-01-16 14:00:29 +08:00
set ( LIBCXX_INSTALL_INCLUDE_DIR "${CMAKE_INSTALL_INCLUDEDIR}/c++/v1" CACHE PATH
2022-01-11 11:03:21 +08:00
" P a t h w h e r e t a r g e t - a g n o s t i c l i b c + + h e a d e r s s h o u l d b e i n s t a l l e d . " )
2022-01-16 14:00:29 +08:00
set ( LIBCXX_INSTALL_RUNTIME_DIR "${CMAKE_INSTALL_BINDIR}" CACHE PATH
2022-01-11 11:03:21 +08:00
" P a t h w h e r e b u i l t l i b c + + r u n t i m e l i b r a r i e s s h o u l d b e i n s t a l l e d . " )
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
" P a t h w h e r e b u i l t l i b c + + l i b r a r i e s s h o u l d b e i n s t a l l e d . " )
2022-01-16 14:00:29 +08:00
set ( LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${CMAKE_INSTALL_INCLUDEDIR}/${LLVM_DEFAULT_TARGET_TRIPLE}/c++/v1" CACHE PATH
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
" P a t h w h e r e t a r g e t - s p e c i f i c l i b c + + h e a d e r s s h o u l d b e i n s t a l l e d . " )
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 ( )
2017-05-04 14:02:50 +08:00
else ( )
2022-01-11 11:03:21 +08:00
if ( LLVM_LIBRARY_OUTPUT_INTDIR )
set ( LIBCXX_LIBRARY_DIR ${ LLVM_LIBRARY_OUTPUT_INTDIR } )
set ( LIBCXX_GENERATED_INCLUDE_DIR "${LLVM_BINARY_DIR}/include/c++/v1" )
else ( )
set ( LIBCXX_LIBRARY_DIR ${ CMAKE_BINARY_DIR } /lib ${ LIBCXX_LIBDIR_SUFFIX } )
set ( LIBCXX_GENERATED_INCLUDE_DIR "${CMAKE_BINARY_DIR}/include/c++/v1" )
endif ( )
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
" P a t h w h e r e b u i l t l i b c + + l i b r a r i e s s h o u l d b e i n s t a l l e d . " )
set ( LIBCXX_INSTALL_INCLUDE_TARGET_DIR "${LIBCXX_INSTALL_INCLUDE_DIR}" CACHE PATH
" P a t h w h e r e t a r g e t - s p e c i f i c l i b c + + h e a d e r s s h o u l d b e i n s t a l l e d . " )
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'
2022-01-15 00:35:53 +08:00
if ( ZOS )
add_target_flags_if_supported ( "-fzos-le-char-mode=ebcdic" )
endif ( )
[CMake] Support CMake variables for setting target, sysroot and toolchain
CMake has a standard way of setting target triple, sysroot and external
toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into
corresponding --target=, --sysroot= and --gcc-toolchain= variables add
included appended to CMAKE_<LANG>_FLAGS.
libunwind, libc++abi, libc++ provides their own mechanism through
<PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN
variables. These are also passed to lit via lit.site.cfg, and lit config
uses these to set the corresponding compiler flags when building tessts.
This means that there are two different ways of setting target, sysroot
and toolchain, but only one is properly supported in lit. This change
extends CMake build for libunwind, libc++abi and libc++ to also support
the CMake variables in addition to project specific ones in lit.
Differential Revision: https://reviews.llvm.org/D57670
llvm-svn: 353084
2019-02-05 04:02:26 +08:00
2022-06-14 09:44:58 +08:00
if ( ${ CMAKE_SYSTEM_NAME } MATCHES "AIX" )
add_target_flags_if_supported ( "-mdefault-visibility-export-mapping=explicit" )
set ( CMAKE_AIX_EXPORT_ALL_SYMBOLS OFF )
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
2022-05-14 00:15:15 +08:00
# Remove flags that may have snuck in.
# TODO: This shouldn't be necessary anymore since we don't support the Project
# build anymore, so the rest of LLVM can't pollute our flags.
remove_flags ( -DNDEBUG -UNDEBUG -D_DEBUG -lc++abi )
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
C X X _ S T A N D A R D 2 0
2021-09-24 00:15:02 +08:00
C X X _ S T A N D A R D _ R E Q U I R E D Y E S
2019-12-12 09:26:30 +08:00
C X X _ E X T E N S I O N S N O )
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
2022-08-02 18:42:04 +08:00
# because they are provided by the dylib itself with the exception of z/OS.
2020-11-13 03:40:35 +08:00
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
2022-03-10 17:47:09 +08:00
if ( C_SUPPORTS_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
- W n o - u n u s e d - p a r a m e t e r - W n o - l o n g - l o n g
2021-10-30 00:36:57 +08:00
- W e r r o r = r e t u r n - t y p e - W e x t r a - s e m i - W u n d e f
- W f o r m a t - n o n l i t e r a l )
2019-10-03 03:31:30 +08:00
if ( "${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang" )
target_add_compile_flags_if_supported ( ${ target } PRIVATE
- W n o - u s e r - d e f i n e d - l i t e r a l s
- W n o - c o v e r e d - s w i t c h - d e f a u l t
2020-07-23 08:44:52 +08:00
- W n o - s u g g e s t - o v e r r i d e
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
- W n o - c + + 9 8 - c o m p a t
2018-10-01 09:31:23 +08:00
- W n o - c + + 9 8 - c o m p a t - p e d a n t i c
2018-10-01 09:15:50 +08:00
- W n o - c + + 1 1 - c o m p a t
- W n o - u n d e f
2018-10-01 09:31:23 +08:00
- W n o - r e s e r v e d - i d - m a c r o
- W n o - g n u - i n c l u d e - n e x t
- W n o - g c c - c o m p a t # For ignoring "'diagnose_if' is a clang extension" warnings
2018-10-01 09:47:23 +08:00
- W n o - z e r o - a s - n u l l - p o i n t e r - c o n s t a n t # FIXME: Remove this and fix all occurrences.
- W n o - d e p r e c a t e d - d y n a m i c - e x c e p t i o n - s p e c # For auto_ptr
- W n o - s i g n - c o n v e r s i o n
- W n o - o l d - s t y l e - c a s t
- W n o - d e p r e c a t e d # FIXME: Remove this and fix all occurrences.
2018-10-01 09:59:37 +08:00
- W n o - s h i f t - s i g n - o v e r f l o w # FIXME: Why do we need this with clang-cl but not clang?
2018-10-01 11:59:05 +08:00
- W n o - d o u b l e - p r o m o t i o n # 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
2022-02-07 23:07:01 +08:00
- W n o - a t t r i b u t e s
2019-10-03 03:31:30 +08:00
- W n o - l i t e r a l - s u f f i x
- W n o - c + + 1 4 - c o m p a t
2020-07-23 08:44:52 +08:00
- W n o - n o e x c e p t - t y p e
- W n o - s u g g e s t - o v e r r i d e )
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 ( )
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 =============================================================
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
N O T u p p e r c a s e _ C M A K E _ B U I L D _ T Y P E S T R E Q U A L " R E L W I T H D E B I N F O " )
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" )
2022-08-13 13:12:28 +08:00
elseif ( USE_SANITIZER STREQUAL "HWAddress" )
append_flags ( SANITIZER_FLAGS "-fsanitize=hwaddress" )
2018-11-14 07:08:31 +08:00
elseif ( USE_SANITIZER MATCHES "Memory(WithOrigins)?" )
2022-04-30 19:17:17 +08:00
append_flags ( SANITIZER_FLAGS -fsanitize=memory )
2018-11-14 07:08:31 +08:00
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
U S E _ S A N I T I Z E R S T R E Q U A L " U n d e f i n e d ; A d d r e s s " )
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 ( )
get_sanitizer_flags ( SANITIZER_FLAGS "${LLVM_USE_SANITIZER}" )
[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.
2022-03-10 17:47:09 +08:00
if ( CXX_SUPPORTS_NOSTDLIBXX_FLAG )
2021-02-17 02:02:22 +08:00
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
2022-03-10 17:47:09 +08:00
if ( CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG AND LIBCXXABI_USE_LLVM_UNWINDER )
Reapply #2 of [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind
This does mostly the same as D112126, but for the runtimes cmake files.
Most of that is straightforward, but the interdependency between
libcxx and libunwind is tricky:
Libunwind is built at the same time as libcxx, but libunwind is not
installed yet. LIBCXXABI_USE_LLVM_UNWINDER makes libcxx link directly
against the just-built libunwind, but the compiler implicit -lunwind
isn't found. This patch avoids that by adding --unwindlib=none if
supported, if we are going to link explicitly against a newly built
unwinder anyway.
Since the previous attempt, this no longer uses
llvm_enable_language_nolink (and thus doesn't set
CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY during the compiler
sanity checks). Setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
during compiler sanity checks makes cmake not learn about some
aspects of the compiler, which can make further find_library or
find_package fail. This caused OpenMP to not detect libelf and libffi,
disabling some OpenMP target plugins.
Instead, require the caller to set CMAKE_{C,CXX}_COMPILER_WORKS=YES
when building in a configuration with an incomplete toolchain.
Differential Revision: https://reviews.llvm.org/D113253
2021-10-24 06:11:20 +08:00
# If we're linking directly against the libunwind that we're building
# in the same invocation, don't try to link in the toolchain's
# default libunwind (which may be missing still).
target_add_link_flags_if_supported ( ${ target } PRIVATE "--unwindlib=none" )
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.
_ A L L O W _ M S C _ V E R _ M I S M A T C H
# 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.
_ A L L O W _ I T E R A T O R _ D E B U G _ L E V E L _ M I S M A T C H
# We are building the c++ runtime, don't pull in
# msvcprt.
_ C R T B L D
# Don't warn on the use of "deprecated"
# "insecure" functions which are standards
# specified.
_ C R T _ S E C U R E _ N O _ W A R N I N G S
# Use the ISO conforming behaviour for conversion
# in printf, scanf.
_ C R T _ S T D I O _ I S O _ W I D E _ S P E C I F I E R S )
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 =====================================================
2022-02-08 03:52:17 +08:00
config_define ( ${ LIBCXX_ABI_VERSION } _LIBCPP_ABI_VERSION )
config_define ( ${ LIBCXX_ABI_NAMESPACE } _LIBCPP_ABI_NAMESPACE )
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] 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 )
2021-08-24 03:32:36 +08:00
config_define_if_not ( LIBCXX_ENABLE_WIDE_CHARACTERS _LIBCPP_HAS_NO_WIDE_CHARACTERS )
2020-11-05 04:01:25 +08:00
config_define_if_not ( LIBCXX_ENABLE_VENDOR_AVAILABILITY_ANNOTATIONS _LIBCPP_HAS_NO_VENDOR_AVAILABILITY_ANNOTATIONS )
[libc++] Make the Debug mode a configuration-time only option
The debug mode has been broken pretty much ever since it was shipped
because it was possible to enable the debug mode in user code without
actually enabling it in the dylib, leading to ODR violations that
caused various kinds of failures.
This commit makes the debug mode a knob that is configured when
building the library and which can't be changed afterwards. This is
less flexible for users, however it will actually work as intended
and it will allow us, in the future, to add various kinds of checks
that do not assume the same ABI as the normal library. Furthermore,
this will make the debug mode more robust, which means that vendors
might be more tempted to support it properly, which hasn't been the
case with the current debug mode.
This patch shouldn't break any user code, except folks who are building
against a library that doesn't have the debug mode enabled and who try
to enable the debug mode in their code. Such users will get a compile-time
error explaining that this configuration isn't supported anymore.
In the future, we should further increase the granularity of the debug
mode checks so that we can cherry-pick which checks to enable, like we
do for unspecified behavior randomization.
Differential Revision: https://reviews.llvm.org/D122941
2022-04-02 04:38:30 +08:00
config_define_if ( LIBCXX_ENABLE_DEBUG_MODE _LIBCPP_ENABLE_DEBUG_MODE )
[libc++] Add a lightweight overridable assertion handler
This patch adds a lightweight assertion handler mechanism that can be
overriden at link-time in a fashion similar to `operator new`.
This is a third take on https://llvm.org/D121123 (which allowed customizing
the assertion handler at compile-time), and https://llvm.org/D119969
(which allowed customizing the assertion handler at runtime only).
This approach is, I think, the best of all three explored approaches.
Indeed, replacing the assertion handler in user code is ergonomic,
yet we retain the ability to provide a custom assertion handler when
deploying to older platforms that don't have a default handler in
the dylib.
As-is, this patch provides a pretty good amount of backwards compatibility
with the previous debug mode:
- Code that used to set _LIBCPP_DEBUG=0 in order to get basic assertions
in their code will still get basic assertions out of the box, but
those assertions will be using the new assertion handler support.
- Code that was previously compiled with references to __libcpp_debug_function
and friends will work out-of-the-box, no changes required. This is
because we provide the same symbols in the dylib as we used to.
- Code that used to set a custom __libcpp_debug_function will stop
compiling, because we don't provide that declaration anymore. Users
will have to migrate to the new way of setting a custom assertion
handler, which is extremely easy. I suspect that pool of users is
very limited, so breaking them at compile-time is probably acceptable.
The main downside of this approach is that code being compiled with
assertions enabled but deploying to an older platform where the assertion
handler didn't exist yet will fail to compile. However users can easily
fix the problem by providing a custom assertion handler and defining
the _LIBCPP_AVAILABILITY_CUSTOM_ASSERTION_HANDLER_PROVIDED macro to
let the library know about the custom handler. In a way, this is
actually a feature because it avoids a load-time error that one would
otherwise get when trying to run the code on the older target.
Differential Revision: https://reviews.llvm.org/D121478
2022-03-04 06:37:03 +08:00
if ( LIBCXX_ENABLE_ASSERTIONS )
config_define ( 1 _LIBCPP_ENABLE_ASSERTIONS_DEFAULT )
else ( )
config_define ( 0 _LIBCPP_ENABLE_ASSERTIONS_DEFAULT )
endif ( )
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 ( )
2021-12-21 07:19:34 +08:00
if ( LIBCXX_EXTRA_SITE_DEFINES )
set ( extra_site_defines )
foreach ( extra_site_define ${ LIBCXX_EXTRA_SITE_DEFINES } )
# Allow defines such as DEFINE=VAL, transformed into "#define DEFINE VAL".
string ( REPLACE "=" " " extra_site_define "${extra_site_define}" )
list ( APPEND extra_site_defines "#define ${extra_site_define}" )
endforeach ( )
string ( REPLACE ";" "\n" extra_site_defines "${extra_site_defines}" )
config_define ( ${ extra_site_defines } _LIBCPP_EXTRA_SITE_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
2022-07-19 22:44:06 +08:00
set ( LIBCXX_TEST_DEPS "cxx_experimental" )
2018-11-15 04:38:46 +08:00
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 )
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 ( )
