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.

133 lines
5.1 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)
Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm" This reverts commit 4af11272f57a4a6fed2932e9e0857b2c1a707c51.
2022-01-22 01:53:14 +08:00
include(CheckLinkerFlag)
[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
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
# The compiler driver may be implicitly trying to link against libunwind.
# This is normally ok (libcxx relies on an unwinder), but if libunwind is
# built in the same cmake invocation as libcxx and we've got
# LIBCXXABI_USE_LLVM_UNWINDER set, we'd be linking against the just-built
# libunwind (and the compiler implicit -lunwind wouldn't succeed as the newly
# built libunwind isn't installed yet). For those cases, it'd be good to
# link with --uwnindlib=none. Check if that option works.
Revert "[cmake] Duplicate `{llvm,compiler_rt}_check_linker_flag` for runtime libs and llvm" This reverts commit 4af11272f57a4a6fed2932e9e0857b2c1a707c51.
2022-01-22 01:53:14 +08:00
llvm_check_linker_flag("--unwindlib=none" LIBCXX_SUPPORTS_UNWINDLIB_NONE_FLAG)
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 (LIBCXX_SUPPORTS_UNWINDLIB_NONE_FLAG)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} --unwindlib=none")
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
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] Cache the compiler-rt library search results There's a lot of duplicated calls to find various compiler-rt libraries from build of runtime libraries like libunwind, libc++, libc++abi and compiler-rt. The compiler-rt helper module already implemented caching for results avoid repeated Clang invocations. This change moves the compiler-rt implementation into a shared location and reuses it from other runtimes to reduce duplication and speed up the build. Differential Revision: https://reviews.llvm.org/D88458
2020-09-29 08:37:20 +08:00
include(HandleCompilerRT)
find_compiler_rt_library(builtins LIBCXX_BUILTINS_LIBRARY
FLAGS ${LIBCXX_COMPILE_FLAGS})
[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_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)
[libc++] Disable coverage with sanitize-coverage=0 When building libcxx, libcxxabi, and libunwind the build environment may specify any number of sanitizers. For some build feature tests these sanitizers must be disabled to prevent spurious linking errors. With -fsanitize= this is straight forward with -fno-sanitize=all. With -fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there is the equivalent undocumented but tested -fsanitize-coverage=0. The current build rules fail to disable 'trace-pc-guard'. By disabling all sanitize-coverage flags, including 'trace-pc-guard', possible spurious linker errors are prevented. In particular, this allows libcxx, libcxxabi, and libunwind to be built with HonggFuzz. CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build configuration steps (like check_cxx_compiler_flag). It does not affect the compile flags for the actual build of the project (unless of course these flags change whether or not a given source compiles and links or not). So libcxx, libcxxabi, and libunwind will still be built with any specified sanitize-coverage as before. The build configuration steps (which are mostly checking to see if certain compiler flags are available) will not try to compile and link "int main() { return 0;}" (or other specified source) with sanitize-coverage (which can fail to link at this stage in building, since the final compile flags required are yet to be determined). The change to LIBFUZZER_CFLAGS was done to keep it consistent with the obvious intention of disabling all sanitize-coverage. This appears to be intentional, preventing the fuzzer driver itself from showing up in any coverage calculations. Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek Differential Revision: https://reviews.llvm.org/D116050
2022-01-08 09:34:05 +08:00
set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -fsanitize-coverage=0")
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
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()