summaryrefslogtreecommitdiffstats
path: root/libcxx/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
...
* [runtimes] Move libunwind, libc++abi and libc++ to lib/ and include/Petr Hosek2019-03-081-9/+11
| | | | | | | | | | | | | | | 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
* [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
* [CMake] Avoid passing -rtlib=compiler-rt when using compiler-rtPetr Hosek2019-02-121-4/+0
| | | | | | | | | | | | We build libc++ and libc++abi with -nodefaultlibs, so -rtlib=compiler-rt has no effect and results in an 'argument unused during compilation' warning which breaks the build when using -Werror. We can therefore drop -rtlib=compiler-rt without any functional change; note that the actual compiler-rt linking is handled by HandleCompilerRT. Differential Revision: https://reviews.llvm.org/D58084 llvm-svn: 353786
* Make LIBCXX_STANDARD_VER configurableEric Fiselier2019-02-101-2/+3
| | | | llvm-svn: 353649
* [CMake] Support CMake variables for setting target, sysroot and toolchainPetr Hosek2019-02-041-4/+19
| | | | | | | | | | | | | | | | | | | | | | CMake has a standard way of setting target triple, sysroot and external toolchain through CMAKE_<LANG>_COMPILER_TARGET, CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN. These are turned into corresponding --target=, --sysroot= and --gcc-toolchain= variables add included appended to CMAKE_<LANG>_FLAGS. libunwind, libc++abi, libc++ provides their own mechanism through <PROJECT>_TARGET_TRIPLE, <PROJECT>_SYSROOT and <PROJECT>_GCC_TOOLCHAIN variables. These are also passed to lit via lit.site.cfg, and lit config uses these to set the corresponding compiler flags when building tessts. This means that there are two different ways of setting target, sysroot and toolchain, but only one is properly supported in lit. This change extends CMake build for libunwind, libc++abi and libc++ to also support the CMake variables in addition to project specific ones in lit. Differential Revision: https://reviews.llvm.org/D57670 llvm-svn: 353084
* Bump the trunk version to 9.0.0svnHans Wennborg2019-01-161-1/+1
| | | | llvm-svn: 351320
* [libcxx] Support building hermetic static libraryPetr Hosek2019-01-061-0/+3
| | | | | | | | | | | | 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
* Rename cxx-benchmark-unittests target and convert to LIT.Eric Fiselier2018-11-141-0/+17
| | | | | | | | | | | | | | This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks and converts the target to use LIT in order to make the tests run faster and provide better output. In particular this runs each benchmark in a suite one by one, allowing more parallelism while ensuring output isn't garbage with multiple threads. Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>' to specify what options are passed when running the benchmarks. llvm-svn: 346888
* Add cxx-benchmark-unittests targetEric Fiselier2018-11-131-22/+32
| | | | | | | | | | | | | 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
* Revert "Build with -fvisibility=hidden"Eric Fiselier2018-10-301-6/+0
| | | | | | | I messed it up somewhere and now the tests aren't linking. Reverting while I investigate. llvm-svn: 345667
* Build with -fvisibility=hiddenEric Fiselier2018-10-301-0/+6
| | | | | | | | | | | | | | | | | | | | | Summary: This change changes the build to use -fvisibility=hidden The exports this patch removes are symbols that should have never been exported by the dylib in the first place, and should all be symbols which the linker won't de-duplicate across SO boundaries, making them safe to remove. After this change, we should be able to apply `_LIBCPP_HIDDEN` to the versioning namespace without changing the export lists. Reviewers: ldionne, mclow.lists Reviewed By: ldionne Subscribers: smeenai, mgorny, libcxx-commits Differential Revision: https://reviews.llvm.org/D53868 llvm-svn: 345664
* Make libc++'s versioning namespace customizableEric Fiselier2018-10-301-0/+10
| | | | | | | | | | | | | | | | | Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
* Remove one more warning from clang-cl buildEric Fiselier2018-10-011-0/+1
| | | | llvm-svn: 343440
* Fix even more Clang warnings.Eric Fiselier2018-10-011-1/+2
| | | | | | | This patch disables shift-sign-overflow warnings for now. It also fixes most -Wfloat-equal warnings and -Wextra-semi warnings. llvm-svn: 343438
* Bump default dialect to C++14 for clang-clEric Fiselier2018-10-011-1/+1
| | | | llvm-svn: 343437
* Remove even more clang-cl warningsEric Fiselier2018-10-011-1/+5
| | | | llvm-svn: 343436
* Remove even more warnings from clang-cl buildEric Fiselier2018-10-011-5/+9
| | | | llvm-svn: 343434
* Turn off warnings under clang-clEric Fiselier2018-10-011-0/+12
| | | | llvm-svn: 343433
* Attempt to unbreak Windows configuration.Eric Fiselier2018-10-011-1/+4
| | | | | | | | | | | 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
* [libc++] Remove Fuchsia-specific knowledge to pick the ABI versionLouis Dionne2018-09-261-7/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: The ABI version used by libc++ is a configuration option just like any other configuration option. It is a knob that can be used by vendors to customize the libc++ that they ship. As such, we should not be hardcoding vendor-specific configuration choices in libc++. When building libc++ for Fuchsia, Fuchsia's build scripts should simply define the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION macro being defined in the __config header that is generated when libc++ is built and installed, which is the correct way to customize libc++'s behavior for specific vendors. Reviewers: phosek, EricWF Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52397 llvm-svn: 343079
* [NFC][libc++] Fix typo in the description of LIBCXX_INCLUDE_BENCHMARKSLouis Dionne2018-09-221-1/+1
| | | | llvm-svn: 342822
* [libcxx] By default, do not use internal_linkage to hide symbols from the ABILouis Dionne2018-08-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
* [CMake] Fix the LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY optionMartin Storsjo2018-08-141-1/+1
| | | | | | | | | | | This option should be available if LIBCXX_ENABLE_SHARED is enabled, not LIBCXX_ENABLE_STATIC. This fixes a typo from SVN r337814. Differential Revision: https://reviews.llvm.org/D50691 llvm-svn: 339697
* Update version to 8.0.0svn: cmake, includes files and docsHans Wennborg2018-08-011-1/+1
| | | | llvm-svn: 338555
* Attempt to unbreak *all the bots*Eric Fiselier2018-07-271-2/+2
| | | | | | | | 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-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Don't generate linker script only when shared library isn't ↵Petr Hosek2018-07-261-2/+2
| | | | | | | | | | | | | statically linked Since r337668, we support statically linking dependencies only to shared or static library. However, that change hasn't updated the check whether to generate a linker script. We shouldn't generate linker script only in the case when we aren't statically linked ABI into the shared library. Differential Revision: https://reviews.llvm.org/D49834 llvm-svn: 338006
* Copy LLVM CMake configuration for CMake Policy CMP0068Eric Fiselier2018-07-261-0/+4
| | | | llvm-svn: 338005
* [CMake] Don't install c++abi headers in standalone libc++ buildPetr Hosek2018-07-251-1/+0
| | | | | | | | | | | 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] Option to control whether shared/static library is installedPetr Hosek2018-07-241-0/+6
| | | | | | | | | | | | | 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
* [CMake] Fix the setting of LIBCXX_HEADER_DIR in standalone buildPetr Hosek2018-07-241-1/+2
| | | | | | | | | | | | 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-0/+8
| | | | | | | | static library" This is a reland of commit r337668. llvm-svn: 337814
* Revert r337727 as it caused Darwin bot failuresAlex Lorenz2018-07-241-1/+1
| | | | llvm-svn: 337782
* [CMake] Fix the setting of LIBCXX_HEADER_DIRHeejin Ahn2018-07-231-1/+1
| | | | | | | | | | Reviewers: phosek Subscribers: mgorny, christof, ldionne, cfe-commits Differential Revision: https://reviews.llvm.org/D49629 llvm-svn: 337727
* Revert "[CMake] Support statically linking dependencies only to shared or ↵Petr Hosek2018-07-231-8/+0
| | | | | | | | 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-0/+8
| | | | | | | | | | | | | | 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] Set per-runtime library directory suffix in runtimes buildPetr Hosek2018-07-101-1/+1
| | | | | | | | | | | | Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal variable used by the runtimes build from individual runtimes, instead set per-runtime librarhy directory suffix variable which is necessary for the sanitized runtimes build to install libraries into correct location. Differential Revision: https://reviews.llvm.org/D49121 llvm-svn: 336713
* Support for multiarch runtimes layoutPetr Hosek2018-06-281-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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] Set the default ABI version for Fuchsia in CMake as wellPetr Hosek2018-04-131-2/+7
| | | | | | | | This is neeeded since the CMake value is used for the SOVERSION. Differential Revision: https://reviews.llvm.org/D45529 llvm-svn: 329983
* Add default C++ ABI libname and include paths for FreeBSDDimitry Andric2018-02-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As noted in a discussion about testing the LLVM 6.0.0 release candidates (with libc++) for FreeBSD, many tests turned out to fail with "exception_ptr not yet implemented". This was because libc++ did not choose the correct C++ ABI library, and therefore it fell back to the `exception_fallback.ipp` header. Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library, and its headers have always been installed in /usr/include/c++/v1, together with the (system) libc++ headers. (Older versions of FreeBSD used GNU libsupc++ by default, but these are now unsupported.) Therefore, if we are building libc++ for FreeBSD, set: * `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt" * `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1" by default. Reviewers: emaste, EricWF, mclow.lists Reviewed By: EricWF Subscribers: mgorny, cfe-commits, krytarowski Differential Revision: https://reviews.llvm.org/D43166 llvm-svn: 324855
* [cmake] [libcxx] Fix find_path() problems when cross compiling.Don Hinton2018-01-221-0/+1
| | | | | | | | | | | | | | | When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY globally which means find_path() always prepends CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH to all paths used in the search. However, this find_path() invocation is looking for a path in the libcxxabi project on the host system, not the target system, which can be done by passing NO_CMAKE_FIND_ROOT_PATH. Differential Revision: https://reviews.llvm.org/D41622 llvm-svn: 323143
* [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 ↵Martin Storsjo2018-01-051-0/+19
| | | | | | | | | | | | | | | | threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
* Update version to 7.0.0svn: cmake, include files and docsHans Wennborg2018-01-031-1/+1
| | | | llvm-svn: 321725
* Include AddLLVM needed for tests in the right contextPetr Hosek2017-12-011-0/+1
| | | | | | | | | | AddLLVM is needed for several functions that are used in tests and as such needs to be included from the right context which previously wasn't the case. Differential Revision: https://reviews.llvm.org/D40280 llvm-svn: 319515
* [libc++] Support Microsoft ABI without vcruntime headersShoaib Meenai2017-10-091-0/+1
| | | | | | | | | | | | | | | | | The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
* [libc++] Clarify names of ABI forcing macrosShoaib Meenai2017-10-051-6/+6
| | | | | | | | | Make it clear that these are intended only to force a specific ABI when the autodetection would give the wrong result by renaming the cmake options and adding separate forcing macros, as suggested by EricWF in the post-commit review of r314949 and further discussed on IRC. llvm-svn: 314965
* [libc++] Move cache variable definition. NFCShoaib Meenai2017-10-041-1/+1
| | | | | | Move it to where the other ABI cache variables/options are defined. llvm-svn: 314950
* [libc++] Allow users to explicitly specify ABIShoaib Meenai2017-10-041-0/+8
| | | | | | | | | | libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls short in some cases. For example, it will detect windows-itanium targets as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility with Microsoft headers). Leave the current heuristic in place by default but also allow users to explicitly specify the ABI if need be. llvm-svn: 314949
* [libc++] Add site config option for ABI macrosShoaib Meenai2017-10-041-0/+13
| | | | | | | | | | | | | | | | | Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
* Resubmit "Fix llvm-lit script generation in libcxx."Zachary Turner2017-09-191-0/+10
| | | | | | | | 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
OpenPOWER on IntegriCloud