summaryrefslogtreecommitdiffstats
path: root/libcxx/lib/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx] Move CMake file to src, avoid using globsPetr Hosek2019-05-011-411/+0
| | | | | | | | | This addresses the longstanding FIXME and makes libc++ build more similar to other runtimes. Differential Revision: https://reviews.llvm.org/D61275 llvm-svn: 359656
* [libc++][CMake] Refactor how we link against system librariesLouis Dionne2019-04-301-39/+55
| | | | | | | | | | | | | | | | | Summary: Instead of populating the global LIBCXX_LIBRARIES, we use the link-time dependency management built into CMake to propagate link flags. This leads to a cleaner and easier-to-follow build. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60969 llvm-svn: 359571
* [libcxx] Update gen_link_script.py to support different input and outputPetr Hosek2019-04-221-1/+2
| | | | | | | | | | This enables the use of this script from other build systems like GN which don't support post-build actions as well as for static archives. Differential Revision: https://reviews.llvm.org/D60309 llvm-svn: 358915
* [CMake] Split linked libraries for shared and static libc++Petr Hosek2019-04-171-11/+13
| | | | | | | | | | | | | Some linker libraries are only needed for shared libc++, some only for static libc++, combining these together in LIBCXX_LIBRARIES and LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies. This changes splits those up into LIBCXX_SHARED_LIBRARIES and LIBCXX_STATIC_LIBRARIES matching what libc++abi already does. Differential Revision: https://reviews.llvm.org/D57872 llvm-svn: 358614
* [CMake] Fix statically linking in libcxxabi if built separatelyMartin Storsjo2019-04-091-2/+2
| | | | | | | | | | | In this case, CMake doesn't know about the c++abi target within the same CMake run. This reverts this aspect back to how it was before SVN r357811. Differential Revision: https://reviews.llvm.org/D60448 llvm-svn: 358009
* [libc++] Remove install_name and compatibility_version on OS XLouis Dionne2019-04-081-2/+0
| | | | | | | | | | | | | | | CMake already specifies those, and we never actually want those to be used. In fact, r357811 re-ordered those flags in a way that the explicitly-provided install_name was overriding the CMake-provided install_name (instead of the other way around). This caused the dylib to be considered a system dylib, and hence the explicitly provided rpath to be ignored. This, in turn, caused some unit tests to start linking against the system libc++.dylib instead of the freshly-built one. Specifically, the unit tests that started linking against the system dylib are those that didn't specify a DYLD_LIBRARY_PATH, such as last_write_time.sh.cpp. llvm-svn: 357946
* [libc++][CMake] Make sure the benchmarks link against libc++abiLouis Dionne2019-04-051-1/+2
| | | | | | | | | | | | | | The refactoring in r357811 made it so that we didn't add the ABI library to the list of LIBCXX_LIBRARIES. As a result, benchmarks didn't link to the ABI library and were missing symbols. This broke the build bots. As a drive-by fix, we also provide the SHARED ABI library to the linker script instead of the STATIC ABI library. This couldn't be discovered on Apple platforms because libc++.dylib re-exports libc++abi.dylib symbols there. llvm-svn: 357818
* [libc++] Localize CMake code only related to the shared libraryLouis Dionne2019-04-051-68/+64
| | | | | | | | | | | | | | | | | | Summary: There's a lot of CMake logic that's only relevant to the shared library, yet it was using a code path and setting variables that impact both the shared and the static libraries. This patch moves this logic so that it clearly only impacts the shared library. Reviewers: phosek, smeenai, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60276 llvm-svn: 357811
* [CMake] Differentiate between static and shared libc++abiPetr Hosek2019-04-031-8/+7
| | | | | | | | | | | | | | | This addresses the issue introduced in r354212 which broke the case when static libc++abi is merged into static libc++, but shared libc++ is linked against shared libc++. There are 4 different possible combinations which is difficult to capture using a single variable. This change splits LIBCXX_CXX_ABI_LIBRARY into two: LIBCXX_CXX_SHARED_ABI_LIBRARY and LIBCXX_CXX_STATIC_ABI_LIBRARY to handle the shared and static cases. This in turn allows simplification of some of the logic around merging of static archives. Differential Revision: https://reviews.llvm.org/D60114 llvm-svn: 357556
* [libc++][CMake] Allow merging libc++abi.a into libc++ even on Apple platformsLouis Dionne2019-03-251-4/+9
| | | | | | | | | | | | | | | | | | | | Summary: I can't see a good reason to disallow this, even though it isn't the standard way we build libc++ for Apple platforms. Making this work on Apple platforms requires using different flags for --whole-archive and removing the -D flag when running `ar` to merge archives because that flag isn't supported by the `ar` shipped on Apple platforms. This shouldn't be an issue since the -D option appears to be enabled by default in GNU `ar`. Reviewers: phosek, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59513 llvm-svn: 356903
* [libc++] Re-export the sjlj ABI v2 for ARM architecturesLouis Dionne2019-03-221-1/+1
| | | | | | We were previously not exporting the right ABI version of libc++abi. llvm-svn: 356798
* Allow disabling of filesystem library.Eric Fiselier2019-03-211-8/+10
| | | | | | | | | | | | | | Summary: Filesystem doesn't work on Windows, so we need a mechanism to turn it off for the time being. Reviewers: ldionne, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: mstorsjo, mgorny, christof, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59619 llvm-svn: 356633
* [libc++][CMake] Clean up some of the libc++ re-exporting logicLouis Dionne2019-03-201-20/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: This change allows specifying the version of libc++abi's ABI to re-export when configuring CMake. It also clearly identifies which ABI version of libc++abi each export file contains. Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS, since that knowledge is not relevant anymore. Indeed, libc++ can't be built with the toolchain that came with the 10.9 SDK anyway because the version of Clang it includes is too old (for example if you want to build a working libc++.dylib, you need bugfixes to visibility attributes that are only in recent Clangs). Reviewers: dexonsmith, EricWF Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits Differential Revision: https://reviews.llvm.org/D59489 llvm-svn: 356587
* [libc++] Build <filesystem> support as part of the dylibLouis Dionne2019-03-191-42/+11
| | | | | | | | | | | | | | | | | | | Summary: This patch treats <filesystem> as a first-class citizen of the dylib, like all other sub-libraries (e.g. <chrono>). As such, it also removes all special handling for installing the filesystem library separately or disabling part of the test suite from the lit command line. Unlike the previous attempt (r356500), this doesn't remove all the filesystem tests. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59152 llvm-svn: 356518
* Revert "[libc++] Build <filesystem> support as part of the dylib"Louis Dionne2019-03-191-11/+42
| | | | | | | | When I applied r356500 (https://reviews.llvm.org/D59152), I somehow deleted all of filesystem's tests. I will revert r356500 and re-apply it properly. llvm-svn: 356505
* [libc++] Build <filesystem> support as part of the dylibLouis Dionne2019-03-191-42/+11
| | | | | | | | | | | | | | | | Summary: This patch treats <filesystem> as a first-class citizen of the dylib, like all other sub-libraries (e.g. <chrono>). As such, it also removes all special handling for installing the filesystem library separately or disabling part of the test suite from the lit command line. Reviewers: mclow.lists, EricWF, serge-sans-paille Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59152 llvm-svn: 356500
* [libc++][CMake] Do not define `cxx_shared_EXPORTS` when building the shared ↵Louis Dionne2019-03-141-0/+1
| | | | | | | | | | | | library CMake will define -Dcxx_shared_EXPORTS when building the shared library by default. In theory, this is used to signal to the library that we're building a shared library and that dllimport/dllexport should be used. However, we already have our own way of doing that, so I'm removing this define to avoid meaningless command line arguments in the build. llvm-svn: 356167
* [libc++][CMake] Fix typo introduced in r356150Louis Dionne2019-03-141-1/+1
| | | | | | That typo broke the build when the shared library build was disabled. llvm-svn: 356155
* [libc++] Do not force building with -fPIC (re-applying)Louis Dionne2019-03-141-4/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: In r355746, we stopped forcing to build with -fPIC because that should be specified by the CMAKE_POSITION_INDEPENDENT_CODE option at CMake configure time (and by default -fPIC is used for shared libraries anyways). However, r355746 had to be reverted in r355756 because we were not actually building the shared library with -fPIC. The reason is that we were sharing an object library between the static and the shared library, which caused flags for static libraries to be used when building object files that were going to be used for a shared library. Since this was resolved by r356150, we can stop forcing -fPIC again. Reviewers: EricWF, smeenai Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59250 llvm-svn: 356153
* [libc++] Do not share an object library to create the static/shared librariesLouis Dionne2019-03-141-38/+19
| | | | | | | | | | | | | | | | | | | | | | Summary: The problem with using an object library for doing this is that it prevents the shared library and the static library from being built with the right default flags. For example, CMake will build shared libraries with -fPIC by default, but not static libraries. Using an object library to create the shared library will prevent the right default flags for shared libraries from being used. As a side effect, this patch also localizes the logic related to building a hermetic static library to the static library case, making clear that this has no effect on the shared library. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D59248 llvm-svn: 356150
* Revert "[libc++] Do not force building with -fPIC"Eric Fiselier2019-03-081-0/+4
| | | | | | | | | | This reverts commit r355764. CMake does not turn -fPIC on for us by default. so this patch breaks standalone builds. The only reason it hasn't broken any bots is because LLVM turns on and specifies '-fPIC' for us. llvm-svn: 355756
* [libc++] Do not force building with -fPICLouis Dionne2019-03-081-4/+0
| | | | | | | | | | | | | | | | Summary: Whether we build with -fPIC should be specified by the CMAKE_POSITION_INDEPENDENT_CODE option at configure time. Note that this patch doesn't change the behavior when building by default, since -fPIC is used for shared libraries by default. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D59146 llvm-svn: 355746
* Revert "[runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/"Matthew Voss2019-03-081-3/+3
| | | | | | | | This broke the windows bots. This reverts commit 28302c66d2586074f77497d5dc4eac7182b679e0. llvm-svn: 355725
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-081-3/+3
| | | | | | | | | | | | | | | This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/<target> and include/ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59013 llvm-svn: 355665
* [libc++] Remove old CMake workaroundLouis Dionne2019-03-041-20/+14
| | | | | | | We haven't had any complaints so far, and I don't think anybody builds libc++ from source for that old platform anymore. llvm-svn: 355336
* Make LIBCXX_STANDARD_VER configurableEric Fiselier2019-02-101-1/+1
| | | | llvm-svn: 353649
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+7
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352688
* Revert "[CMake] Use correct visibility for linked libraries in CMake"Petr Hosek2019-01-301-2/+2
| | | | | | This reverts commit r352654: this broke libcxx and sanitizer bots. llvm-svn: 352658
* [CMake] Use correct visibility for linked libraries in CMakePetr Hosek2019-01-301-2/+2
| | | | | | | | | | | When linking library dependencies, we shouldn't need to export linked libraries to dependents. We should be explicit about this in target_link_libraries, otherwise other targets that depend on these such as sanitizers get repeated (and possibly even conflicting) dependencies. Differential Revision: https://reviews.llvm.org/D57456 llvm-svn: 352654
* [libcxx] Support building hermetic static libraryPetr Hosek2019-01-061-33/+60
| | | | | | | | | | | | This is useful when static libc++ library is being linked into shared libraries that may be used in combination with libraries. We want to avoid we exporting libc++ symbols in those cases where this option is useful. This is provided as a CMake option and can be enabled by libc++ vendors as needed. Differential Revision: https://reviews.llvm.org/D55404 llvm-svn: 350489
* [libcxx] Make sure the re-export logic works when paths contain spacesLouis Dionne2018-11-271-5/+5
| | | | llvm-svn: 347711
* [libcxx] Fix libc++ re-exporting logic when Command Line Tools are not installedLouis Dionne2018-11-271-18/+11
| | | | | | | | | | | | | | | | | | Summary: When the Xcode Command Line tools are not installed but CMAKE_OSX_SYSROOT is set, we would try to re-export symbols from the libc++abi.dylib shipped in the sysroot, which does not exist. This commit changes the build on OS X to always re-export symbols from the explicit re-export lists, which doesn't change depending on what system you're building on, and is therefore much less flaky. Reviewers: EricWF, mclow.lists Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D54595 llvm-svn: 347708
* [libcxx] Remove custom CMake code targeting Mac OS 10.6Louis Dionne2018-10-161-8/+3
| | | | | | | | | | | | | libc++ has dropped support for Mac OS 10.6 for a while, and we don't have any testers set up for that OS. This commit puts in an error message so that people can reach out to the libc++ maintainers in case support for 10.6 is still expected (as opposed to silently failing in weird ways). We can completely drop support for 10.6 and remove the error message some time in the future when we're sure that nobody is relying on it. llvm-svn: 344576
* Add libc++fs to the test deps, and not to the target 'cxx'.Eric Fiselier2018-07-271-7/+3
| | | | llvm-svn: 338096
* Attempt to unbreak *all the bots*Eric Fiselier2018-07-271-4/+6
| | | | | | | | The bots were failing to build the cxx_filesystem target, so the tests were failing. Though this does lead me to wonder how it was ever working with c++experimental. llvm-svn: 338095
* Implement <filesystem>Eric Fiselier2018-07-271-5/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Option to control whether shared/static library is installedPetr Hosek2018-07-241-7/+10
| | | | | | | | | | | | | Currently it's only possible to control whether shared or static library build of libc++, libc++abi and libunwind is enabled or disabled and whether to install everything we've built or not. However, it'd be useful to have more fine grained control, e.g. when static libraries are merged together into libc++.a we don't need to install libc++abi.a and libunwind.a. This change adds this option. Differential Revision: https://reviews.llvm.org/D49573 llvm-svn: 337867
* Reland "[CMake] Support statically linking dependencies only to shared or ↵Petr Hosek2018-07-241-3/+3
| | | | | | | | static library" This is a reland of commit r337668. llvm-svn: 337814
* Revert "[CMake] Support statically linking dependencies only to shared or ↵Petr Hosek2018-07-231-3/+3
| | | | | | | | static library" This reverts commit r337668: broke the cxxabi build when using Make. llvm-svn: 337670
* [CMake] Support statically linking dependencies only to shared or static libraryPetr Hosek2018-07-231-3/+3
| | | | | | | | | | | | | | Currently it's possible to select whether to statically link unwinder or the C++ ABI library, but this option applies to both the shared and static library. However, in some scenarios it may be desirable to only statically link unwinder and C++ ABI library into static C++ library since for shared C++ library we can rely on dynamic linking and linker scripts. This change enables selectively enabling or disabling statically linking only to shared or static library. Differential Revision: https://reviews.llvm.org/D49502 llvm-svn: 337668
* [CMake] Rename cxx_headers back to cxx-headers.Ahmed Bougacha2018-06-281-1/+1
| | | | | | | | | | | | | | r334477 renamed the cxx-headers target to cxx_headers, but various pieces sort-of expect the target names to match the component (e.g., LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via some magic foreign to me, seems to expect cxx-headers, install-cxx-headers, and install-cxx-headers-stripped to exist.) Revert back to cxx-headers. Differential Revision: https://reviews.llvm.org/D48701 llvm-svn: 335899
* [CMake] Use common variable for all header targets NFCPetr Hosek2018-06-121-4/+3
| | | | | | This simplifies the handling of header targets. llvm-svn: 334477
* [CMake] Add a missing target dependency on C++ ABI headersPetr Hosek2018-06-121-1/+1
| | | | | | | This resolves the breakage introduced in r334468 which results in build error when using CMake Makefile generator. llvm-svn: 334470
* Reland "Use custom command and target to install libc++ headers"Petr Hosek2018-06-121-1/+5
| | | | | | | | | | | | | | | | | | | Using file(COPY FILE...) has several downsides. Since the file command is only executed at configuration time, any changes to headers made after the initial CMake execution are ignored. This can lead to subtle errors since the just built Clang will be using stale libc++ headers. Furthermore, since the headers are copied prior to executing the build system, this may hide missing dependencies on libc++ from other LLVM components. This changes replaces the use of file(COPY FILE...) command with a custom command and target which addresses all aforementioned issues and matches the implementation already used by other LLVM components that also install headers like Clang builtin headers. Differential Revision: https://reviews.llvm.org/D44773 llvm-svn: 334468
* Revert "[CMake] Use custom command and target to install libc++ headers"Petr Hosek2018-04-091-2/+1
| | | | | | This reverts commit r329544 which is failing on libcxx standalone bots. llvm-svn: 329545
* [CMake] Use custom command and target to install libc++ headersPetr Hosek2018-04-091-1/+2
| | | | | | | | | | | | | | | | | | | Using file(COPY FILE...) has several downsides. Since the file command is only executed at configuration time, any changes to headers made after the initial CMake execution are ignored. This can lead to subtle errors since the just built Clang will be using stale libc++ headers. Furthermore, since the headers are copied prior to executing the build system, this may hide missing dependencies on libc++ from other LLVM components. This changes replaces the use of file(COPY FILE...) command with a custom command and target which addresses all aforementioned issues and matches the implementation already used by other LLVM components that also install headers like Clang builtin headers. Differential Revision: https://reviews.llvm.org/D44773 llvm-svn: 329544
* [CMake] Copy the generated __config header into build directoryPetr Hosek2018-03-101-1/+1
| | | | | | | | | | | | | | When the generated __config file is being used, it is currently only copied during installation process. However, that means that the file that gets copied into LLVM build directory is the vanilla __config file, and any parts of the build that depend on the just built toolchain like sanitizers will get that instead of the generated version. To avoid this issue, we need to copy the generated header into the LLVM build directory as well. Differential Revision: https://reviews.llvm.org/D43797 llvm-svn: 327194
* LLVM_FOUND isn't always set, so just test if llvm_setup_rpath() isDon Hinton2018-01-271-1/+1
| | | | | | available instead. llvm-svn: 323599
* Reland: [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.Don Hinton2018-01-261-0/+3
| | | | | | | | | Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323492
* Revert [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when ↵Don Hinton2018-01-251-1/+0
| | | | | | | | | | adding shared libraries. Shoaib Meenai pointed out this will break standalone builds when built without llvm. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323459
OpenPOWER on IntegriCloud