maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/cmake/config-ix.cmake

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

119 lines
4.5 KiB
CMake
Raw Normal View History

[runtimes] Use -Wunknown-pragmas for the pragma check This is a follow up to r362055, we need -Wunknown-pragmas otherwise the check is going to succeed it the pragma isn't supported. llvm-svn: 362057
2019-05-30 13:38:06 +08:00
include(CMakePushCheckState)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
include(CheckLibraryExists)
[CMake][libcxx] Use check_c_compiler_flag to check for nodefaultlibs We're using -nodefaultlibs to avoid the dependency on C++ library when using check_cxx_compiler_flag, and as such we cannot use check_cxx_compiler_flag to check the availability of -nodefaultlibs itself. llvm-svn: 299711
2017-04-07 05:06:33 +08:00
include(CheckCCompilerFlag)
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
include(CheckCXXCompilerFlag)
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
include(CheckCSourceCompiles)
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
if(WIN32 AND NOT MINGW)
# NOTE(compnerd) this is technically a lie, there is msvcrt, but for now, lets
# let the default linking take care of that.
set(LIBCXX_HAS_C_LIB NO)
else()
Revert "[CMake] Use __libc_start_main rather than fopen when checking for C library" This reverts commit r352341: it broke the build on macOS which doesn't seem to provide __libc_start_main in its C library. llvm-svn: 352411
2019-01-29 03:26:41 +08:00
check_library_exists(c fopen "" LIBCXX_HAS_C_LIB)
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
endif()
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
if (NOT LIBCXX_USE_COMPILER_RT)
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
if(WIN32 AND NOT MINGW)
set(LIBCXX_HAS_GCC_S_LIB NO)
else()
[libcxx][libcxxabi][libunwind] Use libgcc on Android Android doesn't have a libgcc_s and uses libgcc instead, so adjust the build accordingly. This matches compiler-rt's build setup. libc++abi and libunwind were already checking for libgcc but in a different context. This change makes them search only for libgcc on Android now, but the code to link against libgcc if it were present was already there. Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines Differential Revision: https://reviews.llvm.org/D78787
2020-04-24 12:19:11 +08:00
if(ANDROID)
check_library_exists(gcc __gcc_personality_v0 "" LIBCXX_HAS_GCC_LIB)
else()
check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
endif()
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
endif()
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
endif()
[SystemZ][ZOS] Prefer -nostdlib++ as opposed to -nodefaultlibs when building c++ libraries Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before. This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out. The propose change will allow to make the link step simple for other platforms as well. Reviewed By: #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D95875
2021-02-17 02:02:22 +08:00
# libc++ is using -nostdlib++ at the link step when available,
# otherwise -nodefaultlibs is used. We want all our checks to also
# use one of these options, otherwise we may end up with an inconsistency between
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
# the flags we think we require during configuration (if the checks are
[SystemZ][ZOS] Prefer -nostdlib++ as opposed to -nodefaultlibs when building c++ libraries Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before. This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out. The propose change will allow to make the link step simple for other platforms as well. Reviewed By: #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D95875
2021-02-17 02:02:22 +08:00
# performed without one of those options) and the flags that are actually
# required during compilation (which has the -nostdlib++ or -nodefaultlibs). libc is
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
# required for the link to go through. We remove sanitizers from the
# configuration checks to avoid spurious link errors.
[SystemZ][ZOS] Prefer -nostdlib++ as opposed to -nodefaultlibs when building c++ libraries Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before. This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out. The propose change will allow to make the link step simple for other platforms as well. Reviewed By: #libc, #libc_abi, ldionne Differential Revision: https://reviews.llvm.org/D95875
2021-02-17 02:02:22 +08:00
check_c_compiler_flag(-nostdlib++ LIBCXX_SUPPORTS_NOSTDLIBXX_FLAG)
if (LIBCXX_SUPPORTS_NOSTDLIBXX_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nostdlib++")
else()
check_c_compiler_flag(-nodefaultlibs LIBCXX_SUPPORTS_NODEFAULTLIBS_FLAG)
if (LIBCXX_SUPPORTS_NODEFAULTLIBS_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nodefaultlibs")
endif()
endif()
if (LIBCXX_SUPPORTS_NOSTDLIBXX_FLAG OR LIBCXX_SUPPORTS_NODEFAULTLIBS_FLAG)
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
if (LIBCXX_HAS_C_LIB)
list(APPEND CMAKE_REQUIRED_LIBRARIES c)
endif ()
if (LIBCXX_USE_COMPILER_RT)
[CMake][libcxx] Use builtins rather than gcc_s when compiler-rt is requested When compiler-rt is requested, we should attempt to link compiler-rt builtins library rather than gcc_s. Differential Revision: https://reviews.llvm.org/D31617 llvm-svn: 299599
2017-04-06 06:53:05 +08:00
list(APPEND CMAKE_REQUIRED_FLAGS -rtlib=compiler-rt)
find_compiler_rt_library(builtins LIBCXX_BUILTINS_LIBRARY)
list(APPEND CMAKE_REQUIRED_LIBRARIES "${LIBCXX_BUILTINS_LIBRARY}")
[libcxx][libcxxabi][libunwind] Use libgcc on Android Android doesn't have a libgcc_s and uses libgcc instead, so adjust the build accordingly. This matches compiler-rt's build setup. libc++abi and libunwind were already checking for libgcc but in a different context. This change makes them search only for libgcc on Android now, but the code to link against libgcc if it were present was already there. Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines Differential Revision: https://reviews.llvm.org/D78787
2020-04-24 12:19:11 +08:00
elseif (LIBCXX_HAS_GCC_LIB)
list(APPEND CMAKE_REQUIRED_LIBRARIES gcc)
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
elseif (LIBCXX_HAS_GCC_S_LIB)
list(APPEND CMAKE_REQUIRED_LIBRARIES gcc_s)
endif ()
Try to fix the libcxx build with mingw64 Summary: mingw64 has lots of default libs that libc++ and its test programs should link against. With this patch, cmake now runs successfully with GCC on Windows. Reviewers: mati865, EricWF Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D31518 llvm-svn: 299144
2017-03-31 08:34:05 +08:00
if (MINGW)
# Mingw64 requires quite a few "C" runtime libraries in order for basic
# programs to link successfully with -nodefaultlibs.
libcxx: fix bootstrapping for mingw-w64 Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
2017-05-26 06:37:15 +08:00
if (LIBCXX_USE_COMPILER_RT)
Correct typo: LIBCXXABI_BUILTINS_LIBRARY -> LIBCXX_BUILTINS_LIBRARY llvm-svn: 303929
2017-05-26 06:43:42 +08:00
set(MINGW_RUNTIME ${LIBCXX_BUILTINS_LIBRARY})
libcxx: fix bootstrapping for mingw-w64 Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
2017-05-26 06:37:15 +08:00
else ()
set(MINGW_RUNTIME gcc_s gcc)
endif()
set(MINGW_LIBRARIES mingw32 ${MINGW_RUNTIME} moldname mingwex msvcrt advapi32
shell32 user32 kernel32 mingw32 ${MINGW_RUNTIME}
moldname mingwex msvcrt)
list(APPEND CMAKE_REQUIRED_LIBRARIES ${MINGW_LIBRARIES})
Try to fix the libcxx build with mingw64 Summary: mingw64 has lots of default libs that libc++ and its test programs should link against. With this patch, cmake now runs successfully with GCC on Windows. Reviewers: mati865, EricWF Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D31518 llvm-svn: 299144
2017-03-31 08:34:05 +08:00
endif()
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
if (CMAKE_C_FLAGS MATCHES -fsanitize OR CMAKE_CXX_FLAGS MATCHES -fsanitize)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -fno-sanitize=all")
endif ()
Fix libc++ configuration with -fsanitize-coverage Summary: a recent change (r280015) in libc++ configuration broke LibFuzzer bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/12245 It's not restricted just to that bot; any code that uses the sanitize coverage and configures libc++ hits it. This CL fixes the issue. Reviewers: compnerd Subscribers: aizatsky Differential Revision: https://reviews.llvm.org/D24116 llvm-svn: 280335
2016-09-01 09:38:32 +08:00
if (CMAKE_C_FLAGS MATCHES -fsanitize-coverage OR CMAKE_CXX_FLAGS MATCHES -fsanitize-coverage)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -fno-sanitize-coverage=edge,trace-cmp,indirect-calls,8bit-counters")
endif ()
libc++: perform configuration checks with -nodefaultlibs We're compiling libc++ with -nodefaultlibs, so we should also pass this option during the configuration checks to ensure those checks are consistent with the actual build. The primary motivation here is to ease cross-compilation against a non-standard set of C++ libraries. Previously, the configuration checks would attempt to link against the standard C++ libraries, which would cause link failures when cross-compiling, even though the actual library link would go through correctly (because of the use of -nodefaultlibs and explicitly specifying any needed libraries). This is more correct even ignoring the motivation, however. Patch by Shoaib Meenai! llvm-svn: 280015
2016-08-30 05:33:37 +08:00
endif ()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
# Check compiler pragmas
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
[runtimes] Use -Wunknown-pragmas for the pragma check This is a follow up to r362055, we need -Wunknown-pragmas otherwise the check is going to succeed it the pragma isn't supported. llvm-svn: 362057
2019-05-30 13:38:06 +08:00
cmake_push_check_state()
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -Werror=unknown-pragmas")
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
check_c_source_compiles("
#pragma comment(lib, \"c\")
int main() { return 0; }
" LIBCXX_HAS_COMMENT_LIB_PRAGMA)
[runtimes] Use -Wunknown-pragmas for the pragma check This is a follow up to r362055, we need -Wunknown-pragmas otherwise the check is going to succeed it the pragma isn't supported. llvm-svn: 362057
2019-05-30 13:38:06 +08:00
cmake_pop_check_state()
[runtimes] Check if pragma comment(lib, ...) is supported first This fixes the issue introduced by r362048 where we always use pragma comment(lib, ...) for dependent libraries when the compiler is Clang, but older Clang versions don't support this pragma so we need to check first if it's supported before using it. llvm-svn: 362055
2019-05-30 12:40:21 +08:00
endif()
Add CMake build and fix major Linux blockers. llvm-svn: 121510
2010-12-11 03:47:54 +08:00
# Check libraries
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
if(WIN32 AND NOT MINGW)
# TODO(compnerd) do we want to support an emulation layer that allows for the
# use of pthread-win32 or similar libraries to emulate pthreads on Windows?
set(LIBCXX_HAS_PTHREAD_LIB NO)
set(LIBCXX_HAS_M_LIB NO)
set(LIBCXX_HAS_RT_LIB NO)
[libc++][CMake] Link against libSystem on Apple platforms Instead of manually linking against libm/librt/libpthread, we should be linking against libSystem on Apple platforms, and only that. libm and libpthread are symlinks to libSystem anyway. llvm-svn: 359808
2019-05-03 01:43:48 +08:00
set(LIBCXX_HAS_SYSTEM_LIB NO)
[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
set(LIBCXX_HAS_ATOMIC_LIB NO)
[libc++][CMake] Link against libSystem on Apple platforms Instead of manually linking against libm/librt/libpthread, we should be linking against libSystem on Apple platforms, and only that. libm and libpthread are symlinks to libSystem anyway. llvm-svn: 359808
2019-05-03 01:43:48 +08:00
elseif(APPLE)
check_library_exists(System write "" LIBCXX_HAS_SYSTEM_LIB)
set(LIBCXX_HAS_PTHREAD_LIB NO)
set(LIBCXX_HAS_M_LIB NO)
set(LIBCXX_HAS_RT_LIB NO)
[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
set(LIBCXX_HAS_ATOMIC_LIB NO)
[libcxx{,abi}] Don't link libpthread and libdl on Fuchsia These are a part of the libc so linking these explicitly isn't necessary and embedding these as deplibs causes link time error. This issues was introduced in a9b5fff which changed how we emit deplibs. Differential Revision: https://reviews.llvm.org/D71135
2019-12-07 03:11:31 +08:00
elseif(FUCHSIA)
set(LIBCXX_HAS_M_LIB NO)
set(LIBCXX_HAS_PTHREAD_LIB NO)
set(LIBCXX_HAS_RT_LIB NO)
set(LIBCXX_HAS_SYSTEM_LIB NO)
[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
check_library_exists(atomic __atomic_fetch_add_8 "" LIBCXX_HAS_ATOMIC_LIB)
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
else()
check_library_exists(pthread pthread_create "" LIBCXX_HAS_PTHREAD_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
[libc++][CMake] Link against libSystem on Apple platforms Instead of manually linking against libm/librt/libpthread, we should be linking against libSystem on Apple platforms, and only that. libm and libpthread are symlinks to libSystem anyway. llvm-svn: 359808
2019-05-03 01:43:48 +08:00
set(LIBCXX_HAS_SYSTEM_LIB NO)
[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
check_library_exists(atomic __atomic_fetch_add_8 "" LIBCXX_HAS_ATOMIC_LIB)
build: dont detect libraries for Windows Hard code the defaults for Windows for the time being. The checks really are always going to return the same value. Technically, the pthread linkage is possible, however, it seems better to use the Win32 threading along with the external threading support that we have added. llvm-svn: 290801
2017-01-02 04:20:38 +08:00
endif()