LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40680
llvm-svn: 319959
Using the system default 'ar' might not be the right choice when
cross compiling.
Don't prepend the ar options by a dash, not all ar implementations
support that (llvm-ar doesn't).
Also pass the 's' option when creating the merged library, to create
an index.
Differential Revision: https://reviews.llvm.org/D37134
llvm-svn: 313122
This is essential when building with -nodefaultlibs.
This is similar to what already is done in libcxxabi in SVN r302760.
Differential revision: https://reviews.llvm.org/D37207
llvm-svn: 312498
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33762
llvm-svn: 307615
Previously the explicit instantiation for this was in locale.cpp,
but that didn't make much sense. This patch creates a new vector.cpp
source file to contain the explicit instantiation.
llvm-svn: 305442
Summary:
This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC.
The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well.
Note there are still 2 outstanding exception_ptr/nested_exception test failures.
* `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time.
* `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion.
This patch also gets most of the `<future>` tests passing as well.
Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D32927
llvm-svn: 302393
Previously both the static version of libc++ and the
import library for the DLL had the same name, 'c++.lib'.
This patch renames the static library on Windows to be `libc++.lib`
so it no longer conflicts. This naming convention is consistent with
other windows libraries.
llvm-svn: 300817
Summary:
Recent commits broke the check-cxx-abilist by changing the default OS X to use `-rexport_library` instead of `-reexport_symbol_list`. Apparently `-reexport_library` doesn't export the symbols into `libc++.dylib`s symbol table, whereas `-reexport_symbol_list` does.
This means the change removed ~500 symbols from the symbol table. I've been told this change is non ABI breaking, but it does make it harder to maintain the ABI lists, and hence the ABI.
This patch fixes the issue by switching back to `-reexport_symbol_list`. It still avoid the issues fixed in r299052 by putting the new/delete symbols in a different symbol list file, which is only exported when LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS in OFF.
Reviewers: mehdi_amini, smeenai, dexonsmith
Reviewed By: smeenai
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D31644
llvm-svn: 300390
When compiler-rt is requested, we should attempt to link compiler-rt
builtins library rather than gcc_s.
Differential Revision: https://reviews.llvm.org/D31617
llvm-svn: 299599
Summary:
bad_function_call is currently an empty class, so any object files using
that class will end up with their own copy of its typeinfo, typeinfo
name and vtable, leading to unnecessary duplication that has to be
resolved by the dynamic linker. Instead, give bad_function_call a key
function and put a definition for that key function in libc++ itself, to
centralize the typeinfo and vtable.
This is consistent with the behavior for other exception classes. The
key functions are defined in libc++ rather than libc++abi since the
class is defined in the libc++ versioning namespace, so ABI
compatibility with libstdc++ is not a concern.
Guard this change behind an ABI macro, since it isn't backwards
compatible (i.e., clients built against the new libc++ headers wouldn't
be able to run against an older libc++ library).
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27387
llvm-svn: 298937
Clang doesn't produce gcov compatible coverage files. This
causes lcov to break because it uses gcov by default. This
patch switches lcov to use llvm-cov as the gcov-tool.
Unfortunatly llvm-cov doesn't provide a gcov like interface by
default so it won't work with lcov. However `llvm-cov gcov` does.
For this reason we generate 'llvm-cov-wrapper' script that always
passes the gcov flag.
llvm-svn: 297553
Libc++ frequently creates and uses utilities written in python.
Currently there are python modules under both libcxx/test and
libcxx/util. My goal with these changes is to consolidate them
into a single package under libcxx/utils/libcxx.
llvm-svn: 294644
When building as part of runtimes, there is no predefined order in
which the runtimes are loaded, so the targets from other projects
might not be available. We need to rely on HAVE_<name> variables
instead in that case.
Differential Revision: https://reviews.llvm.org/D29575
llvm-svn: 294553
Summary: This patch allows libc++ to be built against the debug MSVC runtimes instead of just the release ones.
Reviewers: rnk, majnemer, compnerd, smeenai
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D28725
llvm-svn: 292006
Summary:
This patch attempts to fix the libc++ build/link so that it doesn't use an default C++ libraries on Windows. This is needed to prevent linking to MSVC's STL library.
Additionally this patch changes libc++ so that it is always linked with the non-debug DLL's (e.g. `/MD`). This is needed so that the test suite can correctly link the same libraries without needing to know which configuration `c++.dll` was linked with.
Reviewers: compnerd, rnk, majnemer, kimgr, awson, halyavin, smeenai
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28441
llvm-svn: 292001
There is no guaranteed order in which CMake files for individual
runtimes are invoked and therefore we cannot rely on existence of
targets defined in other runtimes. Use the new HAVE_<name> options
instead in those cases.
Differential Revision: https://reviews.llvm.org/D28391
llvm-svn: 291632
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
Use the cmake variables to get the platform dependent values for the
static library prefix and suffix, which can be different from the Unix
preference for "lib", ".a" (e.g. Windows uses "", ".lib" respectively).
llvm-svn: 290939
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290839
Move the windows specific macro definitions for compiling c++ into the
target. Add a number of newer options that are necessary to properly
build libc++ for windows. This ensures that we do not accidentally
autolink msvcprt (Microsoft's C++ runtime library), do not define linker
pragmas which are msvcprt specific, and do not accidentally encode the
incorrect version of the msvc compatibility version.
llvm-svn: 290837
Disable the manifest bundling on Windows when cross-compiling on
not-Windows. With this, it is possible to execute the link command from
CMake which will use cmake to invoke the manifest tool to generate a
manifest and pass that to the linker.
llvm-svn: 290836
Convert the Solaris xlocale.c compatibility library from plain C to C++
in order to fix the build failures caused by the addition of -std=c++11
to LIBCXX_COMPILE_FLAGS. The additional flag got propagated to the C
file, resulting in error with strict compilers.
Differential Revision: https://reviews.llvm.org/D25431
llvm-svn: 284494
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
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
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
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
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
`-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
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
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
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 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
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
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
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
Shoaib Meenai