summaryrefslogtreecommitdiffstats
path: root/libcxx/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove two ABI symbols added after the 3.9 releaseEric Fiselier2016-10-141-2/+0
| | | | llvm-svn: 284200
* Add ABI changelog entry for <any>Eric Fiselier2016-10-141-0/+10
| | | | llvm-svn: 284199
* Sort ABI lists by name so that changes don't generate big diffsEric Fiselier2016-10-144-5191/+5191
| | | | llvm-svn: 284198
* Revert r284193 - it is not correct on OS XEric Fiselier2016-10-141-22/+20
| | | | llvm-svn: 284194
* Re-export two previously exported std::string functions.Eric Fiselier2016-10-141-20/+22
| | | | | | | These functions were removed from the dylib sometime between the 3.9 release and now. This patch manually exports them to re-gain ABI compatibility. llvm-svn: 284193
* Add ABI list for 3.9 linuxEric Fiselier2016-10-141-0/+2010
| | | | llvm-svn: 284192
* Add 3.9 symbol list for OS XEric Fiselier2016-10-141-0/+2448
| | | | llvm-svn: 284189
* Fix CMake configuration error and add ABI lists for OS X.Eric Fiselier2016-10-142-1/+553
| | | | | | | | | | | | The primary reason for this patch is to add the OS X ABI lists for 3.9 and ToT. However while working on that I discovered that we incorrectly exported the libc++abi symbols. Previously we had chosen the wrong CMake configuration path and that caused us to re-export the c++abi binary instead of using the symbol lists. llvm-svn: 284188
* Add OS X abi listEric Fiselier2016-10-141-0/+1907
| | | | llvm-svn: 284186
* Add ABI Changelog and current symbol list for LinuxEric Fiselier2016-10-143-0/+2058
| | | | llvm-svn: 284185
* Fix linker script generation for in-tree buildsEric Fiselier2016-10-091-21/+26
| | | | llvm-svn: 283700
* [CMake] Fix in-tree libcxxabi build support after r283659Hal Finkel2016-10-091-5/+10
| | | | | | | | | | | r283659 changed the argument to gen_link_script.py from SCRIPT_ABI_LIBNAME to LIBCXX_LIBRARIES_PUBLIC, assuming that all of the items in the LIBCXX_LIBRARIES_PUBLIC list were library names. This is not right, however, for in-tree libcxxabi builds, we might have the target name in this list. There was special logic to fixup SCRIPT_ABI_LIBNAME for this situation; change it to apply a similar fixup for LIBCXX_LIBRARIES_PUBLIC. llvm-svn: 283684
* [cmake] Split linked libraries into private & public, for linker scriptMichal Gorny2016-10-081-7/+24
| | | | | | | | | | | | | | | Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that holds 'public' interface libraries -- that is, libraries that both libc++ links to and programs linked against it need to link to. Currently this includes the ABI library and optionally -lunwind (when LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the linker script, in order to make it possible to link C++ programs using clang with compiler-rt runtime out-of-the-box. Differential Revision: https://reviews.llvm.org/D25008 llvm-svn: 283659
* [libcxx] Allow sanitizing libcxx with ASan+UBSan simultaneouslyKuba Brecka2016-09-151-1/+3
| | | | | | | | Allow building with LLVM_USE_SANITIZER=“Address;Undefined” (and “Undefined;Address”). Differential Revision: https://reviews.llvm.org/D24569 llvm-svn: 281603
* [libcxx] Enable building and testing of libcxx with ThreadSanitizer on OS XKuba Brecka2016-09-141-0/+2
| | | | | | | | This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMake builds that have -DLLVM_USE_SANITIZER=Thread will automatically build libcxx with -fsanitize=thread and testing via lit then runs under TSan. Differential Revision: https://reviews.llvm.org/D24297 llvm-svn: 281475
* [libcxx] Introduce an externally-threaded libc++ variant.Asiri Rathnayake2016-09-111-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch further decouples libc++ from pthread, allowing libc++ to be built against other threading systems. There are two main use cases: - Building libc++ against a thread library other than pthreads. - Building libc++ with an "external" thread API, allowing a separate library to provide the implementation of that API. The two use cases are quite similar, the second one being sligtly more de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API enables both kinds of builds. One needs to place an <__external_threading> header file containing an implementation of the "libc++ thread API" declared in the <__threading_support> header. For the second use case, the implementation of the libc++ thread API can delegate to a custom "external" thread API where the implementation of this external API is provided in a seperate library. This mechanism allows toolchain vendors to distribute a build of libc++ with a custom thread-porting-layer API (which is the "external" API above), platform vendors (recipients of the toolchain/libc++) are then required to provide their implementation of this API to be linked with (end-user) C++ programs. Note that the second use case still requires establishing the basic types that get passed between the external thread library and the libc++ library (e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources won't compile otherwise). It should also be noted that the second use case can have a slight performance penalty; as all the thread constructs need to cross a library boundary through an additional function call. When the header <__external_threading> is omitted, libc++ is built with the "libc++ thread API" (declared in <__threading_support>) as the "external" thread API (basic types are pthread based). An implementation (pthread based) of this API is provided in test/support/external_threads.cpp, which is built into a separate DSO and linked in when running the libc++ test suite. A test run therefore demonstrates the second use case (less the intermediate custom API). Differential revision: https://reviews.llvm.org/D21968 Reviewers: bcraig, compnerd, EricWF, mclow.lists llvm-svn: 281179
* build: don't add -fPIC on WindowsSaleem Abdulrasool2016-09-011-1/+3
| | | | | | | | | `-fPIC` doesn't make much sense for Windows, since Windows DLLs aren't compiled position independent and are instead relocated at runtime. Patch by Shoaib Meenai! llvm-svn: 280413
* Fix syntax error in recent CMake change.Eric Fiselier2016-08-301-1/+1
| | | | llvm-svn: 280042
* Fix PR28831 - Bad logic around CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES.Eric Fiselier2016-08-301-2/+2
| | | | | | | See https://llvm.org/bugs/show_bug.cgi?id=28831 for more information about the changes. llvm-svn: 280037
* [CMake] Be more consistent about naming targets and componentsChris Bieneman2016-08-241-5/+6
| | | | | | | | | | | | | | | Summary: The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name. This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later. Reviewers: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D23699 llvm-svn: 279675
* Allow building both shared and static libraryPetr Hosek2016-08-081-22/+49
| | | | | | | | | This change allows building both shared and static version of libc++ in a single build, sharing object files between both versions. Differential Revision: https://reviews.llvm.org/D23232 llvm-svn: 278068
* Rework libatomic handling in CMake and LIT.Eric Fiselier2016-07-181-1/+1
| | | | | | | | | | | | | | | This patch updates the way libc++ handles checking for libatomic, in part to prepare for https://reviews.llvm.org/D22073. Changes: * 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++ doesn't need to manually link it. * 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic needs to be manually linked. * 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the test suite. llvm-svn: 275759
* Add Filesystem TS -- CompleteEric Fiselier2016-06-171-1/+4
| | | | | | | | | | | | | | Add the completed std::experimental::filesystem implementation and tests. The implementation supports C++11 or newer. The TS is built as part of 'libc++experimental.a'. Users of the TS need to manually link this library. Building and testing the TS can be disabled using the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'. Currently 'libc++experimental.a' is not installed by default. To turn on the installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'. llvm-svn: 273034
* Automatically detect export lists for OS X.Eric Fiselier2016-06-141-1/+15
| | | | | | | | | | | | | | | | | | Summary: Libc++ reexports symbols from the system libc++abi using -reexport_symbols_list. This can cause a linker failure if the list contains symbols not defined in the system libc++abi. This patch attempts to detect the OS X version and use it to determine the correct symbol list. It's my understanding that `lib/libc++abi2.exp` should be used on 10.9 and greater. Otherwise 'lib/libc++abi.exp' should be used This fixes PR25666 (https://llvm.org/bugs/show_bug.cgi?id=25666) Reviewers: mclow.lists, bcraig, dexonsmith, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D20772 llvm-svn: 272723
* [libcxx] Prefer C++14 over C++11 when building libc++experimental.Eric Fiselier2016-05-101-1/+7
| | | | | | | | | | | | | | | | | | Summary: Currently libc++experimental builds with C++11. This patch changes that to C++14 when supported by the compiler. Although nothing currently requires C++14 the upcoming <experimental/memory_resource> implementation would benefit from it. [1] Note that libc++.so continues to build with C++11 and is unaffected by this change. [1] <experimental/memory_resource> provides global resources which must exist for the entire lifetime of the program. In order to ensure that a global resource can be used during program termination there destructors must never be invoked. The only way to do this, while also allowing "constant initialization", is to use a C++14 union. Reviewers: mclow.lists Subscribers: pete, cfe-commits Differential Revision: http://reviews.llvm.org/D19992 llvm-svn: 269070
* Create new library 'libc++experimental.a' for packaging TS symbols.Eric Fiselier2016-05-031-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Out-of-line symbols for <experimental/...> headers are not ABI or API stable and cannot live in the 'libc++.dylib'. Currently they have nowhere to live. I would like to add a new library target `libc++experimental.a` to fix this. Previously I had suggested different libraries for different TS's (`libc++filesystem.a`, 'libc++LFTS.a`, ect). I no longer think this is the right approach. Instead `c++experimental` will hold *all* TS implementations as a single monolithic library. I see two main benefits to this: 1. Users only have to know about and manually link one library. 2. It makes it easy to implement TS's with one or two out-of-line symbols. (Ex. PMRs) `c++experimental` provides NO ABI compatibility. Symbols can freely be added/removed/changed without concern for ABI stability. I will add documentation for this after landing this patch (but before adding anything to it). `c++experimental` only builds as a static library. By default CMake will build/test this library but will *NOT* install it. This patch adds the CMake and LIT logic needed to build/test the new library. Once this lands I plan on using it to implement parts of `<experimental/memory_resource>`. Reviewers: mclow.lists Subscribers: cfe-commits, theraven, krememek, dexonsmith, bcraig, beanz, danalbert Differential Revision: http://reviews.llvm.org/D19856 llvm-svn: 268443
* Fix dependencies on install-libcxx CMake targetEric Fiselier2016-05-031-3/+3
| | | | llvm-svn: 268363
* [CMake] Create a separate install target for libcxx headersChris Bieneman2016-04-291-1/+4
| | | | | | This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers. llvm-svn: 268124
* Re-commit "Introduce a cmake module to figure out whether we need to link ↵Vasileios Kalintiris2016-02-111-0/+1
| | | | | | | | | | with libatomic." This re-applies commit r260235. However, this time we add -gcc-toolchain to the compiler's flags when the user has specified the LIBCXX_GCC_TOOLCHAIN variable. llvm-svn: 260515
* Revert "Introduce a cmake module to figure out whether we need to link with ↵Vasileios Kalintiris2016-02-091-1/+0
| | | | | | | | | | | libatomic." This reverts commit r260235. It breaks LLVM's bootstrap when building with a -gcc-toolchain and the system's gcc installation does not provide the libatomic library and its headers. We should check whether LIBCXX_GCC_TOOLCHAIN is set and adjust the flags accordingly. llvm-svn: 260323
* Introduce a cmake module to figure out whether we need to link with libatomic.Vasileios Kalintiris2016-02-091-0/+1
| | | | | | | | | | | | | | Summary: This fixes the tests under std/atomics for 32-bit MIPS CPUs where the 8-byte atomic operations call into the libatomic library. Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D16613 llvm-svn: 260235
* [libcxx] Remove -Wpadded from buildit script.Akira Hatanaka2016-01-271-1/+1
| | | | | | | | | | Per discussion with Eric and Joerg, this commit removes -Wpadded to silence the warning about the padding inserted at the tail of struct _Rep_base. rdar://problem/23932550 llvm-svn: 258900
* Add CMake option LIBCXX_CONFIGURE_IDE to allow for other IDE's.Eric Fiselier2015-12-161-1/+1
| | | | | | CLion needs similar configuration changes as MSVC_IDE and XCODE. llvm-svn: 255851
* [CMake] If you're not installing the libcxx library, exclude it from the ↵Chris Bieneman2015-12-031-3/+10
| | | | | | | | "all" target so it doesn't get built when you run "ninja install" This is just a build dependency optimization. Running check-libcxx will still build libcxx and function as expected, it just removes libcxx from the all build and install targets. llvm-svn: 254628
* Use proper output directory when naminging the libc++ outputEric Fiselier2015-10-231-1/+1
| | | | llvm-svn: 251100
* Dont required CMake 3 to install a linker scriptEric Fiselier2015-10-221-2/+3
| | | | llvm-svn: 251065
* Re-enable linker scripts after fixing bad CMakeEric Fiselier2015-10-151-1/+1
| | | | llvm-svn: 250472
* Use correct CMake variable for the libnameEric Fiselier2015-10-141-1/+1
| | | | llvm-svn: 250329
* [libcxx] Make it drastically simpler to link libc++.Eric Fiselier2015-10-141-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like: ``` clang++ -stdlib=libc++ foo.cpp -lc++abi ``` Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like: ``` # libc++.so INPUT(libc++.so.1 -lc++abi) ``` With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler. The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin. Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12508 llvm-svn: 250319
* ABI versioning macros for libc++.Evgeniy Stepanov2015-10-131-2/+2
| | | | | | | | C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
* [libcxx] Reexport std::bad_array_length symbols from libc++abi on OS X.Eric Fiselier2015-10-052-1/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: On OS X libc++ needs to reexport libc++abi's symbols in order for them to be provided. We explicitly list the symbols to reexport it libcxx/lib/libc++abi2.exp. This patch adds the symbols required by std::bad_array_length which have been missing for some time. However there is a problem. std::bad_array_length was add to libc++abi in September of 2013 by commit r190479, about a year after everything else. Therefore I think older OS X version have libc++abi versions without std::bad_array_length. On those systems libc++ won't build with this change because we will try and export undefined symbols. The workaround I would write to support older systems depends on the amount of people who would need it. If only a small number of developers are affected it might be sufficient to provide a CMake switch like `LIBCPP_LIBCPPABI_HAS_BAD_ARRAY_LENGTH` which is ON by default and can be disabled by those who need it. Otherwise I think we should try to automatically detect if the symbols are present in `/usr/lib/libc++abi.dylib` and configure accordingly. I would prefer the first solution because writing CMake sucks. Reviewers: mclow.lists, aprantl Subscribers: aprantl, cfe-commits Differential Revision: http://reviews.llvm.org/D13445 llvm-svn: 249339
* [libcxx] Remove installation rules on Darwin when it would overwrite the ↵Eric Fiselier2015-08-261-10/+13
| | | | | | | | | | | | | | | | | system installation. Summary: On Mac OS X overwriting `/usr/lib/libc++.dylib` can cause your computer to fail to boot. This patch tries to make it harder to do that accidentally. If `CMAKE_SYSTEM_NAME` is `Darwin` and `CMAKE_INSTALL_PREFIX` is `/usr` don't generate installation rules unless the user explicitly provides `LIBCXX_OVERRIDE_DARWIN_INSTALL=ON`. Note that `CMAKE_INSTALL_PREFIX` is always absolute so we don't need to worry about things like `/usr/../usr`. Reviewers: mclow.lists, beanz, jroelofs Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D12209 llvm-svn: 246070
* [libcxx] Add "install-libcxx" target.Eric Fiselier2015-08-191-2/+10
| | | | | | | | | | | | Summary: Currently you can't install libc++ from within the LLVM tree without installing all of LLVM. This patch adds an install rule for libc++. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11697 llvm-svn: 245470
* Reapply working parts of CMake cleanup.Eric Fiselier2015-07-301-43/+25
| | | | | | | This patch adds the working parts of r243503. The difference with this patch is that it doesn't include the HandleLLVMOptions.cmake file. llvm-svn: 243698
* Revert recent CMake changes again due to failing compiler-rt buildsEric Fiselier2015-07-291-25/+43
| | | | llvm-svn: 243593
* Recommit r243503 "[libcxx] Cleanup CMake configuration and integrate with LLVM"Eric Fiselier2015-07-291-43/+25
| | | | | | | | | This change was reverted in r243550 because it broke clang-format builds (see PR24306). This patch recommits a fixed version of the original. llvm-svn: 243574
* Revert r243503 "[libcxx] Cleanup CMake configuration and integrate with LLVM"Hans Wennborg2015-07-291-25/+43
| | | | | | This caused clang-format to stop linking on Mac; see PR24306. llvm-svn: 243550
* [libcxx] Cleanup CMake configuration and integrate with LLVMEric Fiselier2015-07-291-43/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch contains the following changes: 1. Require that libc++ can find a LLVM source directory. This is done the same way as `libc++abi` currently does. 2. Cleanup ugly configuration code in CMakeLists.txt by using `add_flags`, `add_flags_if`, and `add_flags_if_supported` macros. The goals for this patch are: 1. Help libc++ be more consistent with how LLVM handles CMake options (see PR23670 PR23671). 2. Make it easier to use sanitizers using the `LLVM_USE_SANITIZER` option. 3. Make libc++'s CMakeLists.txt file easier to understand and change. 4. Move towards allowing libc++ to create Sphinx documentation (see http://efcs.ca/libcxx-docs). 5. Move towards allowing libc++ to use other LLVM utilities such as `not` and `FileCheck`. Reviewers: mclow.lists, jroelofs, danalbert Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11308 llvm-svn: 243503
* [libcxx] Add support for sanitizers on OS X.Eric Fiselier2015-07-221-0/+26
| | | | | | | | | | | | Summary: This patch adds special configuration logic to find the compiler_rt libraries required by sanitizers on OS X. The supported sanitizers are Address and Undefined. Reviewers: mclow.lists Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11381 llvm-svn: 242858
* [libcxx] Add code coverage configuration to CMake and LIT.Eric Fiselier2015-03-311-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds configuration to CMake and LIT for running the libc++ test-suite to generate code coverage. To use code coverage use following instructions. * Find the clang resource dir using `$CXX -print-search-dirs`. Let <library-dir> be the first library search directory. * `cmake <regular-options> -DLIBCXX_GENERATE_COVERAGE=ON -DLIBCXX_COVERAGE_LIBRARY=<library-dir>/lib/<platform>/libclang_rt.profile.a <source>` * `make cxx` * `make check-libcxx` * `make generate-libcxx-coverage` The reason I want this patch upstreamed is so I can setup a bot that generates code coverage and posts in online for every revision. Reviewers: mclow.lists, jroelofs, danalbert Reviewed By: danalbert Differential Revision: http://reviews.llvm.org/D8716 llvm-svn: 233669
OpenPOWER on IntegriCloud