summaryrefslogtreecommitdiffstats
path: root/libcxx/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx{,abi}] Don't link libpthread and libdl on FuchsiaPetr Hosek2019-12-061-0/+5
| | | | | | | | | 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
* [libc++] Fix linker script generationPetr Hosek2019-10-111-1/+3
| | | | | | | | | | Handle the case when libc++abi and libunwind are being built together with libc++ in the runtimes build. This logic was used in the previous implementation but dropped in r374116. Differential Revision: https://reviews.llvm.org/D68791 llvm-svn: 374510
* [libc++] Workaround old versions of CMake that don't understand list(JOIN)Louis Dionne2019-10-081-1/+1
| | | | llvm-svn: 374120
* [libc++] Move the linker script generation step to CMakeLouis Dionne2019-10-081-0/+50
| | | | | | | | | | | | | | | | | | Summary: This allows the linker script generation to query CMake properties (specifically the dependencies of libc++.so) instead of having to carry these dependencies around manually in global variables. Notice the removal of the LIBCXX_INTERFACE_LIBRARIES global variable. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D68343 llvm-svn: 374116
* [libc++] Add a CMake cache for Apple-specific configuration optionsLouis Dionne2019-09-111-0/+15
| | | | llvm-svn: 371638
* Provide a meaningful diagnostic when LLVM_PATH doesn't point to a directoryLouis Dionne2019-08-191-0/+3
| | | | llvm-svn: 369312
* Revert "[libc++] Take 3: Do not cleverly link against libc++abi just because ↵Louis Dionne2019-08-081-1/+1
| | | | | | | | | | | it happens to be there" This also reverts "[libc++] Remove temporary hack for D63883". Clearly, I don't understand how the Linux build bots are configured. Differential Revision: https://reviews.llvm.org/D63883 llvm-svn: 368238
* [libc++] Take 3: Do not cleverly link against libc++abi just because it ↵Louis Dionne2019-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | happens to be there Summary: Otherwise, when libcxxabi is not an enabled project in the monorepo, we get a link error because we try to link against non-existent cxxabi_shared. More generally, we shouldn't change the behavior of the build based on implicit things like whether a file happens to be at a specific path or not. This is a re-application of r365222 that had been reverted in r365233 and then r365359 because it broke the build bots. The build bots should now specify explicitly what ABI library they want to use (libc++abi), so this commit should now be OK to merge. It takes a while for build bots to pick up configuration changes, which is why this failed the last time around. Differential Revision: https://reviews.llvm.org/D63883 llvm-svn: 368213
* Revert "[libc++] Take 2: Do not cleverly link against libc++abi just because ↵Vitaly Buka2019-07-081-1/+1
| | | | | | | | | | | | | | it happens to be there" r365326 still breaks bots: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/20712/steps/ninja%20build%20local/logs/stdio http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/39477/steps/test%20tsan%20in%20debug%20compiler-rt%20build/logs/stdio And probably others This reverts commit 945b9ec0693390ef35fe8c6b774495312246b8b6. llvm-svn: 365359
* [libc++] Take 2: Do not cleverly link against libc++abi just because it ↵Louis Dionne2019-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | happens to be there Summary: Otherwise, when libcxxabi is not an enabled project in the monorepo, we get a link error because we try to link against non-existent cxxabi_shared. More generally, we shouldn't change the behavior of the build based on implicit things like whether a file happens to be at a specific path or not. This is a re-application of r365222 that had been reverted in r365233 because it broke the build bots. However, the build bots now specify explicitly what ABI library they want to use (libc++abi), so this commit should now be OK to merge. Differential Revision: https://reviews.llvm.org/D63883 llvm-svn: 365326
* Revert "[libc++] Do not cleverly link against libc++abi just because it ↵Louis Dionne2019-07-051-1/+1
| | | | | | | | happens to be there" This reverts r365222, which broke the libc++ build bots. llvm-svn: 365233
* [libc++] Do not cleverly link against libc++abi just because it happens to ↵Louis Dionne2019-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | be there Summary: Otherwise, when libcxxabi is not an enabled project in the monorepo, we get a link error because we try to link against non-existent cxxabi_shared. More generally, we shouldn't change the behavior of the build based on implicit things like whether a file happens to be at a specific path or not. Reviewers: EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D63883 llvm-svn: 365222
* [libcxx][libcxxabi] Remove the unused CMake checksPetr Hosek2019-05-301-9/+0
| | | | | | | | | | | These seemed to have been used in the past but were since removed by the add_compile_flags_if_supported functions that combine these these checks and adding the flag, but the original checks were never removed. Differential Revision: https://reviews.llvm.org/D62566 llvm-svn: 362058
* [runtimes] Use -Wunknown-pragmas for the pragma checkPetr Hosek2019-05-301-0/+4
| | | | | | | 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
* [runtimes] Check if pragma comment(lib, ...) is supported firstPetr Hosek2019-05-301-1/+9
| | | | | | | | | 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
* [libc++][CMake] Link against libSystem on Apple platformsLouis Dionne2019-05-021-0/+7
| | | | | | | | 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
* [libcxx] cmake - guard list removeBrian Cain2019-05-021-4/+6
| | | | | | | REMOVE_ITEM fails if CMAKE_REQUIRED_LIBRARIES is empty on some versions of cmake. llvm-svn: 359755
* [libc++][CMake] Refactor how we link against system librariesLouis Dionne2019-04-301-0/+24
| | | | | | | | | | | | | | | | | 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
* [CMake] Split linked libraries for shared and static libc++Petr Hosek2019-04-171-8/+0
| | | | | | | | | | | | | 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] Differentiate between static and shared libc++abiPetr Hosek2019-04-031-14/+18
| | | | | | | | | | | | | | | 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] Clean up some of the libc++ re-exporting logicLouis Dionne2019-03-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | 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
* [compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld2019-02-171-1/+1
| | | | | | | | | | | | | | | This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
* Support tests in freestandingJF Bastien2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding `main` isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its `return` statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the `return` we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare `main` as `int main(int, char**` so it mangles consistently (enabling us to declare another `extern "C"` main for freestanding which calls the mangled one), and adds `return 0;` to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with `-x c`, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086
* Revert "[CMake] Use __libc_start_main rather than fopen when checking for C ↵Petr Hosek2019-01-281-1/+1
| | | | | | | | | 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
* [cmake] Fix get_llvm_lit_path() to respect LLVM_EXTERNAL_LIT alwaysMichal Gorny2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT, and require the fallback to be defined explicitly as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone after r346888. The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache variable and an optional pre-definition of default value from caller (e.g. libcxx). It included a hack to make this work by assigning the value back and forth but it was fragile and stopped working in libcxx. The new logic is simpler and more transparent. Default value is provided in a separate variable, and used only when user-specified variable is empty (i.e. not overriden). Differential Revision: https://reviews.llvm.org/D57282 llvm-svn: 352374
* [CMake] Use __libc_start_main rather than fopen when checking for C libraryPetr Hosek2019-01-281-1/+1
| | | | | | | | | | | | | | | | | | The check_library_exists CMake uses a custom symbol definition. This is a problem when checking for C library symbols because Clang recognizes many of them as builtins, and returns the -Wbuiltin-requires-header (or -Wincompatible-library-redeclaration) error. When building with -Werror which is the default, this causes the check_library_exists check fail making the build think that C library isn't available. To avoid this issue, we should use a symbol that isn't recognized by Clang and wouldn't cause the same issue. __libc_start_main seems like reasonable choice that fits the bill. Differential Revision: https://reviews.llvm.org/D57142 llvm-svn: 352341
* [CMake] Passthrough CFLAGS when checking the compiler-rt pathPetr Hosek2018-11-141-0/+3
| | | | | | | | | | This is needed when cross-compiling for a different target since CFLAGS may contain additional flags like -resource-dir which change the location in which compiler-rt builtins are found. Differential Revision: https://reviews.llvm.org/D54371 llvm-svn: 346820
* Add cxx-benchmark-unittests targetEric Fiselier2018-11-131-0/+23
| | | | | | | | | | | | | This patch adds the cxx-benchmark-unittests target so we can start getting test coverage on the benchmarks, including building with sanitizers. Because we're only looking for test-coverage, the benchmarks run for the shortest time possible, and in parallel. The target is excluded from all by default. It only builds and runs the libcxx configurations of the benchmarks, and not any versions built against the systems native standard library. llvm-svn: 346811
* [CMake] Use just basename when copying C++ ABI headersPetr Hosek2018-10-041-1/+1
| | | | | | | | | | This avoids duplicate directories when the filename includes path. Fixes PR39145 Differential Revision: https://reviews.llvm.org/D52762 llvm-svn: 343753
* Attempt to unbreak Windows configuration.Eric Fiselier2018-10-011-0/+1
| | | | | | | | | | | Although libc++ doesn't yet support Windows we still have Windows builders to track our progress. Currently the clang-cl configuration seems broken because it doesn't support -std=c++11 and instead requires /std:c++11. This patch attempts to fix this. llvm-svn: 343431
* [CMake] Don't install c++abi headers in standalone libc++ buildPetr Hosek2018-07-251-1/+1
| | | | | | | | | | | This is a refinement on r337833. Previously we were installing two copies of c++abi headers in libc++ build directory, one in include/c++build and another one in include/c++/v1. However, the second copy is unnecessary when building libc++ standalone. Differential Revision: https://reviews.llvm.org/D49752 llvm-svn: 337979
* [CMake] Fix the setting of LIBCXX_HEADER_DIR in standalone buildPetr Hosek2018-07-241-6/+8
| | | | | | | | | | | | This is an alternative approach to r337727 which broke the build because libc++ headers were copied into the location outside of directories used by Clang. This change sets LIBCXX_HEADER_DIR to different values depending on whether libc++ is being built as part of LLVM w/ per-target multiarch runtime, LLVM or standalone. Differential Revision: https://reviews.llvm.org/D49711 llvm-svn: 337833
* 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] Install C++ ABI headers into the right locationPetr Hosek2018-07-201-10/+2
| | | | | | | | | | | This is a follow-up to r335809 and r337118. While libc++ headers are now installed into the right location in both standard as well as multiarch runtimes layout, turned out C++ ABI headers are still installed into the old location in the latter case. This change addresses that. Differential Revision: https://reviews.llvm.org/D49584 llvm-svn: 337630
* Support for multiarch runtimes layoutPetr Hosek2018-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
* [CMake] Convert paths to the right form in standalone builds on WindowsMartin Storsjo2018-06-202-3/+7
| | | | | | | | | | | | | The paths output from llvm-config --cmakedir and from clang --print-libgcc-file-name can contain backslashes, while CMake can't handle the paths in this form. This matches what compiler-rt already does (since SVN r203789 and r293195). Differential Revision: https://reviews.llvm.org/D48356 llvm-svn: 335172
* [CMake] Use common variable for all header targets NFCPetr Hosek2018-06-121-2/+2
| | | | | | This simplifies the handling of header targets. llvm-svn: 334477
* [CMake] Add a missing target dependency on C++ ABI headersPetr Hosek2018-06-121-0/+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-7/+17
| | | | | | | | | | | | | | | | | | | 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-17/+7
| | | | | | 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-7/+17
| | | | | | | | | | | | | | | | | | | 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
* [libcxx][cmake] Remove libatomic temporarily from CMAKE_REQUIRED_LIBRARIES ↵Simon Dardis2018-04-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | when configuring When libcxx is built in tree for a host which requires libatomic, LLVM's configuration steps will determine it is required and add it to CMAKE_REQUIRED_LIBRARIES. When libcxx is later configured, it tests if it has C++ atomics without libatomic. The test erroneously passes as libatomic is already part of the set of required libraries. In turn, a number of the atomic tests will fail as they require libatomic but the test suite is configured not to use libatomic. Address this by always dropping libatomic from the set of required libraries before determining if LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB is true, then restoring the set of required libraries. Reviewers: EricWF Differential Revision: https://reviews.llvm.org/D43509 llvm-svn: 329167
* [cmake] Always respect existing CMAKE_REQUIRED_FLAGS when adding additional ↵Don Hinton2018-01-231-1/+1
| | | | | | | | ones. * Previously part of https://reviews.llvm.org/D41622. llvm-svn: 323171
* Fix installation of cxxabi.h through libc++.Eric Fiselier2017-11-251-1/+1
| | | | | | | | | | Previously, the install command for the cxxabi headers specified the wrong component, and therefore they were not being included in the install-cxx command. This patch corrects the component name. llvm-svn: 318989
* Make libcxx tests work when llvm sources are not present.Zachary Turner2017-09-201-7/+10
| | | | | | | | | | | | | | | | | | | Despite a strong CMake warning that this is an unsupported libcxx build configuration, some bots still rely on being able to check out lit and libcxx independently with no LLVM sources, and then run lit against libcxx. A previous patch broke that workflow, so this is making it work again. Unfortunately, it breaks generation of the llvm-lit script for libcxx, but we will just have to live with that until a solution is found that allows libcxx to make more use of llvm build pieces. libcxx can still run tests by using the ninja check target, or by running lit.py directly against the build tree or source tree. Differential Revision: https://reviews.llvm.org/D38057 llvm-svn: 313763
* Resubmit "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-0/+5
| | | | | | | | After speaking with the libcxx owners, they agreed that this is a bug in the bot that needs to be fixed by the bot owners, and the CMake changes are correct. llvm-svn: 313643
* Revert "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-5/+0
| | | | | | | | | | | | This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9. There is a bot that is checking out libcxx and lit with nothing else and then running lit.py against the test tree. Since there's no LLVM source tree, there's no LLVM CMake. CMake actually reports this as a warning saying unsupported libcxx configuration, but I guess someone is depending on it anyway. llvm-svn: 313607
* Fix llvm-lit script generation in libcxx.Zachary Turner2017-09-191-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D37997 llvm-svn: 313606
OpenPOWER on IntegriCloud