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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@339874 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338095 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338093 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@338006 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337979 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337867 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337833 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337668 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@336713 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@335809 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@324855 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@323143 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@321896 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@315234 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@314965 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@314949 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@314946 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@313643 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@313607 91177308-0d34-0410-b5e6-96231b3b80d8
If we define cmake macros that require a site config, and then undefine
all such macros, a stale site config header will be left behind.
Explicitly delete any generate site config if we don't need one to avoid
this.
Differential Revision: https://reviews.llvm.org/D36720
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@313284 91177308-0d34-0410-b5e6-96231b3b80d8
r296685 started adding the test/ subdirectory even when
LIBCXX_INCLUDE_TESTS=OFF. This is great for testing libcxx standalone,
but it also breaks the build when the test/ subdirectory is removed
(and our submission system strips all test/ directories).
This patch updates the logic to check for test/ before adding it.
rdar://problem/31931366
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@302095 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.
Differential Revision: https://reviews.llvm.org/D32320
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300921 91177308-0d34-0410-b5e6-96231b3b80d8
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. We also
don't have to pass the target triple when checking for compiler-rt
since that flag is already included in compile flags now.
Differential Revision: https://reviews.llvm.org/D32068
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300409 91177308-0d34-0410-b5e6-96231b3b80d8
DLLs on Windows are treated as runtime targets. Explicitly set the
output directory for them, to be consistent with other platforms.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@300206 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@297553 91177308-0d34-0410-b5e6-96231b3b80d8
