This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.
It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.
Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314
Differential Revision: https://reviews.llvm.org/D117617
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!
It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up
- Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.
- Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.
I figured it was time to make a new revision.
I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.
---
As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.
These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.
Reviewed By: #libunwind, #libc, #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D99484
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
Phabricator Review:
https://reviews.llvm.org/D99836
A couple of parallel patterns still remains serial - "Parallel partial sort", and "Parallel transform scan" - there are //TODOs in the code.
This way, we do not need to set LLVM_CMAKE_PATH to LLVM_CMAKE_DIR when (NOT LLVM_CONFIG_FOUND)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D107717
These paths are needed when building with per-target runtime directories.
(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)
Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.
Fixed since previous attempt: Don't check if the runtimes directory
is the root of the CMake invocation; when the main LLVM CMake
build builds runtimes, it does invoke a sub-CMake with this directory
as the root too, just as if manually invoking CMake at the runtimes
directory. Instead check whether LLVM_TOOLS_BINARY_DIR was set and
whether find_package(LLVM) succeeded or not.
Differential Revision: https://reviews.llvm.org/D107895
These paths are needed when building with per-target runtime directories.
(It's possible to fix this by manually setting these when invoking
cmake, but one isn't supposed to need to do that.)
Also set LLVM_TOOLS_BINARY_DIR while touching this area (as it's
also unset in this case) even if it isn't specifically needed by the
per-target runtime configuration.
Differential Revision: https://reviews.llvm.org/D107895
Even though the standalone build is deprecated, some people are still
relying on it (including libc++ itself for some configurations). Setting
the target triple will ensure that the build and the test suite behaves
consistently in the standalone and normal builds.
Differential Revision: https://reviews.llvm.org/D106800
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.
This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.
One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.
Differential Revision: https://reviews.llvm.org/D106082
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
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.
Differential Revision: https://reviews.llvm.org/D97572
Always turn on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS, if libcxxrt is used
as the C++ ABI library, since libcxxrt does not provide the full set
ofnew and delete operators. In particular, the aligned versions of these
operators are completely missing. This primarily addresses builds on
FreeBSD, as this platform uses libcxxrt by default.
Also, attempt to provide a FreeBSD.cmake cache file, with hopefully sane
settings, partially copied from the Apple.cmake cache file. This needs
more work, probably some additions to ci build scripts (although I am
not aware of any 'official' FreeBSD build bots).
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D96720
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.
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
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
As explained in https://gitlab.kitware.com/cmake/cmake/-/issues/21045,
both branches of an $<IF> generator expression are evaluated eagerly
by CMake. As a result, if the non-selected branch contains an invalid
generator expression (such as getting the OUTPUT_NAME property of a
non-existent target), a hard error will occur.
This failed builds using the cxxrt ABI library, which doesn't create
a CMake target currently.
Instead of having complex logic around how to include the libc++ headers
and __config_site, handle that by defining cxx-headers as an INTERFACE
library and linking against it. After this patch, linking against cxx-headers
is sufficient to get the right __config_site include and include paths
for libc++.
Differential Revision: https://reviews.llvm.org/D82702
Since we can always find the rest of the LLVM tree, we can always run the
tests in the standalone mode. Do it so that the default behavior is the
same in the standalone and non-standalone modes.
Since we require that libc++ is built as part of the monorepo layout, we
can assume the path of the rest of LLVM and avoid requiring that LLVM_PATH
be set explicitly.
We've decided to move away from that by requiring that libc++ is built
as part of the monorepo a while ago. This commit removes code pertaining
to that unsupported use case and produces a clear error when the user
violates that.
In fact, building outside of the monorepo will still work as long as
LLVM_PATH is pointing to the root of the LLVM project, although that
is not officially supported.
Before this patch, the __config_site header was only generated when at
least one __config_site macro needed to be defined. This lead to two
different code paths in how libc++ is configured, depending on whether
a __config_site header was generated or not. After this patch, the
__config_site is always generated, but it can be empty in case there
are no macros to define in it.
More context on why this change is important
--------------------------------------------
In addition to being confusing, this double-code-path situation lead to
broken code being checked in undetected in 2405bd6898, which introduced
the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake setting. Specifically,
the _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT <__config_site> macro was
supposed NOT to be defined unless LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
was specified explicitly on the CMake command line. Instead, what happened
is that it was defined to 0 if it wasn't specified explicitly and a
<__config_site> header was generated. And defining that macro to 0 had
the important effect of using the non-unique RTTI comparison implementation,
which changes the ABI.
This change in behavior wasn't noticed because the <__config_site> header
is not generated by default. However, the Apple configuration does cause
a <__config_site> header to be generated, which lead to the wrong RTTI
implementation being used, and to https://llvm.org/PR45549. We came close
to an ABI break in the dylib, but were saved due to a downstream-only
change that overrode the decision of the <__config_site> for the purpose
of RTTI comparisons in libc++abi. This is an incredible luck that we should
not rely on ever again.
While the problem itself was fixed with 2464d8135e by setting
LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT explicitly in the Apple
CMake cache and then in d0fcdcd28f by making the setting less
brittle, the point still is that we should have had a single code
path from the beginning. Unlike most normal libraries, the macros
that configure libc++ are really complex, there's a lot of them and
they control important properties of the C++ runtime. There must be
a single code path for that, and it must be simple and robust.
Differential Revision: https://reviews.llvm.org/D80927
When testing libc++ for our cross-compiled CheriBSD target we specify an
explicit LIBCXX_CXX_ABI_INCLUDE_PATHS for libcxxrt. The hardcoded path
/usr/include/c++/v1 was introduced in 61e89737c5
and overrides any value passed on the CMake command line. Fix this by using
it as a fallback rather than a fixed default value.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D82095
Before this patch, we tried detecting whether small atomics were available
without linking against libatomic. However, that's not really what we want
to know -- instead, we want to know what's required in order to support
atomics fully, which is to link against libatomic when it's provided.
That is both much simpler, and it doesn't suffer the problem that we would
not link against libatomic when small atomics didn't require it, which
lead to non-lockfree atomics never working.
Furthermore, because we understand that some platforms might not want to
(or be able to) ship non-lockfree atomics, we add that notion to the test
suite, independently of a potential extern library.
After this patch, we therefore:
(1) Link against libatomic when it is provided
(2) Independently detect whether non-lockfree atomics are supported in
the test suite, regardless of whether that means we're linking against
an external library or not (which is an implementation detail).
Differential Revision: https://reviews.llvm.org/D81190
Chromium's build sets LIBCXX_CXX_ABI_SYSTEM explicitly when building
libc++, which was broken by 61e89737c5 (which stopped listening to
that option). As a workaround, this commit uses the system libc++abi
when LIBCXX_CXX_ABI_SYSTEM is used.
However, we will need to work with Chromium to standardize their build
of libc++, because LIBCXX_CXX_ABI_SYSTEM is not a public facing build
configuration for libc++, and has never been AFAICT.
The 'runtimes' build started failing because libc++ stopped using the
in-tree libc++abi when HAVE_CXXABI is set after 61e89737c. This commit
tries to bring back the old behavior when HAVE_CXXABI is set in order
to fix CIs.
However, we really need to sit down and discuss what ways of building
libc++ are supported and formalize them, because having the libc++ build
system branch on basically random variables in some CMake cache somewhere
is not a viable path forward.
In standalone builds the cxxabi_shared and cxxabi_static targets don't exist.
We need to link against the library itself.
Differential Revision: https://reviews.llvm.org/D77294
This commit removes support for building against the system libc++abi,
which was supported on Apple platforms. This is basically never what we
want to do, since libc++ and libc++abi are coupled and building a trunk
libc++ against an older libc++abi can lead to incompatibilities (and
good luck debugging them!). It might have made some sense to support
that when the monorepo did not exist, however I don't think this is
anything but a footgun nowadays.
Furthermore, based on the newly-made assumption that we're building
against the monorepo libc++abi, we can simplify the search path logic
for finding libc++abi.
This area of our build system has a lot of technical debt accumulated,
and it's surprisingly difficult to change. We've tried different things
and failed several times in the past. I did test this change on our
Docker image for the build bots and on Apple platforms, however it is
possible that this breaks some unknown configuration, in which case it
should be fine to revert this (so we can try again!).
Summary:
This is NFC. We only add additional information to the log.
Reviewers: EricWF, ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: kristof.beyls, dexonsmith, danielkiss, mgorny, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75991
Handle the case when libc++abi and libunwind are being built together
with libc++ in the runtimes build. This logic was used in the previous
implementation but dropped in r374116.
Differential Revision: https://reviews.llvm.org/D68791
llvm-svn: 374510
Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68343
llvm-svn: 374116
This also reverts "[libc++] Remove temporary hack for D63883".
Clearly, I don't understand how the Linux build bots are configured.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 368238
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
This is a re-application of r365222 that had been reverted in r365233
and then r365359 because it broke the build bots. The build bots
should now specify explicitly what ABI library they want to use
(libc++abi), so this commit should now be OK to merge. It takes a while
for build bots to pick up configuration changes, which is why this failed
the last time around.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 368213
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
This is a re-application of r365222 that had been reverted in r365233
because it broke the build bots. However, the build bots now specify
explicitly what ABI library they want to use (libc++abi), so this
commit should now be OK to merge.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 365326
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 365222
John Ericson