Previously, these had to be set manually when building each of the
projects standalone, in order to get proper symbol visibility when
combining the two libraries.
Differential Revision: https://reviews.llvm.org/D90021
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
In 5d796645, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable,
which broke users of the Standalone build. This patch reinstates that
variable, however it must point to the *installed* path of the libc++
headers, not the libc++ headers in the source tree (which has always
been the case, but wasn't enforced before).
If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source
tree, the `__config_site` header will fail to be found.
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
Setting _LIBCPP_HAS_NO_THREADS is needed when building libcxxabi without
threads in standalone mode. This is useful when target WASM. Otherwise,
you get an error like "No thread API" when building libcxxabi.
It would be better to link against a properly-configured libc++ headers
CMake target when building libc++abi instead, but we don't generate such
targets yet.
Thanks to Matthew Bauer for the patch.
Differential Revision: https://reviews.llvm.org/D60743
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
This is necessary for standalone builds where the libc++ in use has a
custom configuration set up inside __config_site -- one needs to build
libc++abi against the installed headers of libc++ (which are properly
configured) instead of the ones inside libcxx/include.
See https://reviews.llvm.org/rGe619e9d#927848 for details.
Since we have the monorepo, libc++abi's build requires a sibling checkout
of the libc++ sources. Hence, the logic for finding libc++ can be greatly
simplified.
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
To avoid wasting the valuable time of contributors, add a link to a
blocked review to document additional issues with the removal of some
GCC 4.9 workaround.
We will soon start removing technical debt and sharing code between the
two directories, so this first step is meant to discover potential places
where the libraries are built outside of a monorepo layout. I imagine
this could happen as a remnant of the pre-monorepo setup.
This was discussed on the libcxx-dev mailing list and we got overall
consensus on the direction. All consumers of libc++ and libc++abi
should already be doing so through the monorepo, however it is
possible that we catch some stragglers with this patch, in which
case it may need to be reverted temporarily.
Differential Revision: https://reviews.llvm.org/D76102
Summary:
Right now the only way to force libc++abi tests to link with the static version of libc++abi is to set `LIBCXXABI_ENABLE_SHARED` to `OFF`. However, this doesn't work when libc++abi is built as standalone project because of [this](54c5224203/libcxxabi/CMakeLists.txt (L503-L519)).
This change allows specifying the version of the library for tests to link with.
This is useful for remote testing, for example, with `SSHExecutor`, where we _have_ to link with libc++abi statically.
Two new CMake options are introduced here: `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI` and `LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXX`. They can be set to `OFF` to tell the test utility to link tests with the static libraries.
It shouldn't break anything, because the default values of these options are set such that the test utility will behave the same way.
Reviewers: EricWF, mclow.lists, phosek, mehdi_amini, ldionne, jroelofs, bcraig
Subscribers: mgorny, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71894
This is a followup to 35bc5276ca. It fixes the dependent libs usage
in libcxx and libcxxabi to link pthread and rt libraries only if CMake
detects them, rather than based on explicit platform blacklist.
Differential Revision: https://reviews.llvm.org/D70888
We build with `-nostdinc++` and add our own header path via
`LIBCXXABI_LIBCXX_INCLUDES`. However cmake tried to be clever and if
`LIBCXXABI_LIBCXX_INCLUDES` happens to match the compilers system path
it will remove the `-I` flag meaning we can't access any C++ headers.
Ideally cmake would be able see that we are using `-nostdinc++` and
disable this behaviour.
Differential Revision: https://reviews.llvm.org/D69973
That option controls the 'VERSION' attribute of the libc++abi shared
library, which in turn controls the name of the actual dylib being
produced.
llvm-svn: 373949
When exceptions are disabled, avoid their processing altogether.
This avoids pulling in the depenency on demangler significantly
reducing binary size when statically linking against libc++abi
built without exception support.
Differential Revision: https://reviews.llvm.org/D64191
llvm-svn: 365944
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
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/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
This change introduces support for building libcxxabi. The library
build should be complete, but not all CMake options have been
replicated in GN. We also don't support tests yet.
We only support two stage build at the moment.
Differential Revision: https://reviews.llvm.org/D60372
llvm-svn: 359805
This is on by default, since on many platforms and configurations
libc++abi.a gets statically linked into shared libraries and/or
PIE executables.
This change is a followup to https://reviews.llvm.org/D60005 which
allows us to default to PIC code, but disable this if needed (for
example on WebAssembly where PIC code its currently compatible with
static linking).
Differential Revision: https://reviews.llvm.org/D60049
llvm-svn: 357551
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 the static libc++abi library is being linked into
shared libraries that may be used in with other shared libraries that
use different C++ library. We want to avoid avoid exporting libc++abi
or libc++ symbols in those cases. This achieved by a new CMake option
which can be enabled by libc++abi vendors as needed.
Differential Revision: https://reviews.llvm.org/D56026
llvm-svn: 352017
Summary:
rL337867 introduced two new cmake_dependent_option options:
- LIBCXXABI_INSTALL_STATIC_LIBRARY
- LIBCXXABI_INSTALL_SHARED_LIBRARY
They depend on LIBCXXABI_ENABLE_STATIC and LIBCXXABI_ENABLE_SHARED
and so therefore need to (it seems) come after the declaration of
these two options.
Subscribers: mgorny, aheejin, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D49825
llvm-svn: 337982
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
Martin Storsjö