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

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

55 lines
1.9 KiB
CMake
Raw Normal View History

[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
# This CMake module is responsible for setting the standard library to libc++
# if the user has requested it.
[CMake] Move the setting of LLVM_COMPILER_IS_GCC_COMPATIBLE to a separate file Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used. Move the setting of this variable into DetermineGCCCompatible and include that from both AddLLVM and HandleLLVMStdlib. Differential Revision: http://reviews.llvm.org/D13216 llvm-svn: 248798
2015-09-29 22:33:58 +08:00
include(DetermineGCCCompatible)
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
if(NOT DEFINED LLVM_STDLIB_HANDLED)
set(LLVM_STDLIB_HANDLED ON)
Teach the LLVM CMake build how to explicitly use libc++abi when using libc++. This lets me almost self-host on Linux with libc++ and libc++abi very simply. Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and the Go binding tests are failing to build due to not linking in the correct C++ standard library. llvm-svn: 231560
2015-03-07 18:30:34 +08:00
function(append value)
foreach(variable ${ARGN})
set(${variable} "${${variable}} ${value}" PARENT_SCOPE)
endforeach(variable)
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
endfunction()
include(CheckCXXCompilerFlag)
[CMake][llvm] avoid conflict w/ (and use when available) new builtin check_linker_flag Match the API for the new check_linker_flag and use it directly when available, leaving the old code as a fallback. Differential Revision: https://reviews.llvm.org/D100901
2021-04-03 14:51:17 +08:00
include(LLVMCheckLinkerFlag)
Add libc++ to link XRay test cases if libc++ is used to build CLANG Summary: When libc++ is used to build CLANG, its XRay libraries libclang_rt.xray-*.a have dependencies on libc++. Therefore, libc++ is needed to link and run XRay test cases. For Linux -rpath is also needed to specify where to load libc++. This change sets macro LLVM_LIBCXX_USED to 1 if libc++ is actually used in the build. XRay tests then check the flag and add -L<llvm_shlib_dir> -lc++ and -Wl,-rpath=<llvm_shlib_dir> if needed. Reviewers: hubert.reinterpretcast, amyk, dberris, jasonliu, sfertile, EricWF Subscribers: dberris, mgorny, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61016 llvm-svn: 360060
2019-05-07 01:45:21 +08:00
set(LLVM_LIBCXX_USED 0)
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
if(LLVM_ENABLE_LIBCXX)
if(LLVM_COMPILER_IS_GCC_COMPATIBLE)
[cmake] Fix libc++ detection -stdlib=libc++ is added to both the compilation and the link flags, but the logic for adding it was only checking if it was supported during compilation and not linking. This could lead to false positives, for example when using clang with libstdc++ (where the compiler would support -stdlib=libc++ but then linking would fail because of libc++ actually being unavailable). llvm-svn: 330761
2018-04-25 03:47:39 +08:00
check_cxx_compiler_flag("-stdlib=libc++" CXX_COMPILER_SUPPORTS_STDLIB)
[CMake][llvm] avoid conflict w/ (and use when available) new builtin check_linker_flag Match the API for the new check_linker_flag and use it directly when available, leaving the old code as a fallback. Differential Revision: https://reviews.llvm.org/D100901
2021-04-03 14:51:17 +08:00
llvm_check_linker_flag(CXX "-stdlib=libc++" CXX_LINKER_SUPPORTS_STDLIB)
[cmake] Fix libc++ detection -stdlib=libc++ is added to both the compilation and the link flags, but the logic for adding it was only checking if it was supported during compilation and not linking. This could lead to false positives, for example when using clang with libstdc++ (where the compiler would support -stdlib=libc++ but then linking would fail because of libc++ actually being unavailable). llvm-svn: 330761
2018-04-25 03:47:39 +08:00
if(CXX_COMPILER_SUPPORTS_STDLIB AND CXX_LINKER_SUPPORTS_STDLIB)
Teach the LLVM CMake build how to explicitly use libc++abi when using libc++. This lets me almost self-host on Linux with libc++ and libc++abi very simply. Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and the Go binding tests are failing to build due to not linking in the correct C++ standard library. llvm-svn: 231560
2015-03-07 18:30:34 +08:00
append("-stdlib=libc++"
CMAKE_CXX_FLAGS CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS)
Add libc++ to link XRay test cases if libc++ is used to build CLANG Summary: When libc++ is used to build CLANG, its XRay libraries libclang_rt.xray-*.a have dependencies on libc++. Therefore, libc++ is needed to link and run XRay test cases. For Linux -rpath is also needed to specify where to load libc++. This change sets macro LLVM_LIBCXX_USED to 1 if libc++ is actually used in the build. XRay tests then check the flag and add -L<llvm_shlib_dir> -lc++ and -Wl,-rpath=<llvm_shlib_dir> if needed. Reviewers: hubert.reinterpretcast, amyk, dberris, jasonliu, sfertile, EricWF Subscribers: dberris, mgorny, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61016 llvm-svn: 360060
2019-05-07 01:45:21 +08:00
set(LLVM_LIBCXX_USED 1)
Teach the LLVM CMake build how to explicitly use libc++abi when using libc++. This lets me almost self-host on Linux with libc++ and libc++abi very simply. Currently, MCJIT and OrcJIT are failing due to uncaught exceptions, and the Go binding tests are failing to build due to not linking in the correct C++ standard library. llvm-svn: 231560
2015-03-07 18:30:34 +08:00
else()
message(WARNING "Can't specify libc++ with '-stdlib='")
endif()
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
else()
message(WARNING "Not sure how to specify libc++ for this compiler")
endif()
endif()
Add support in CMake to statically link the C++ standard library. It is sometimes useful to have the C++ standard library linked into the assembly when compiling clang, particularly when distributing a compiler onto systems that don't have a copy of stdlibc++ or libc++ installed. This functionality should work with either GCC or Clang as the host compiler, though statically linking libc++ (as may be required for licensing purposes) is only possible if the host compiler is Clang with a copy of libc++ available. Differential Revision: https://reviews.llvm.org/D65603 llvm-svn: 368907
2019-08-15 03:55:59 +08:00
if(LLVM_STATIC_LINK_CXX_STDLIB)
if(LLVM_COMPILER_IS_GCC_COMPATIBLE)
check_cxx_compiler_flag("-static-libstdc++"
CXX_COMPILER_SUPPORTS_STATIC_STDLIB)
[CMake][llvm] avoid conflict w/ (and use when available) new builtin check_linker_flag Match the API for the new check_linker_flag and use it directly when available, leaving the old code as a fallback. Differential Revision: https://reviews.llvm.org/D100901
2021-04-03 14:51:17 +08:00
llvm_check_linker_flag(CXX "-static-libstdc++" CXX_LINKER_SUPPORTS_STATIC_STDLIB)
Add support in CMake to statically link the C++ standard library. It is sometimes useful to have the C++ standard library linked into the assembly when compiling clang, particularly when distributing a compiler onto systems that don't have a copy of stdlibc++ or libc++ installed. This functionality should work with either GCC or Clang as the host compiler, though statically linking libc++ (as may be required for licensing purposes) is only possible if the host compiler is Clang with a copy of libc++ available. Differential Revision: https://reviews.llvm.org/D65603 llvm-svn: 368907
2019-08-15 03:55:59 +08:00
if(CXX_COMPILER_SUPPORTS_STATIC_STDLIB AND
CXX_LINKER_SUPPORTS_STATIC_STDLIB)
append("-static-libstdc++"
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS)
else()
message(WARNING
"Can't specify static linking for the C++ standard library")
endif()
else()
message(WARNING "Not sure how to specify static linking of C++ standard "
"library for this compiler")
endif()
endif()
[CMake] Move -stdlib=libc++ handling into its own file. r200744 moved this into cmake/config-ix.cmake, so that it would happen very early in the build process. However, standalone builds of Clang and other external projects never include this file (which is correct). Now, -stdlib=libc++ and the LLVM_COMPILER_IS_GCC_COMPATIBLE option are both set in a new include file, HandleLLVMStdlib, which is included by both config-ix.cmake and HandleLLVMOptions.cmake. This preserves existing behavior for projects relying on HandleLLVMOptions and still does the right thing for builds of LLVM itself. llvm-svn: 200811
2014-02-05 08:02:37 +08:00
endif()