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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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++'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
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
Matthew Voss