We always strive to test libc++ as close as possible to the way we are
actually shipping it. This was approximated reasonably well by setting
up the minimal driver flags when running the test suite, however we were
running the test suite against the library located in the build
directory.
This patch improves the situation by installing the library (the
headers, the built library, modules, etc) into a fake location and then
running the test suite against that fake "installation root".
This should open the door to getting rid of the temporary copy of the
headers we make during the build process, however this is left for a
future improvement.
Note that this adds quite a bit of verbosity whenever running the test
suite because we install the headers beforehand every time. We should be
able to override this to silence it, however CMake doesn't currently
give us a way to do that, see https://gitlab.kitware.com/cmake/cmake/-/issues/26085.
In order to test libc++ under the "Apple System Library" configuration,
we need to run the tests using DYLD_LIBRARY_PATH. This is required
because libc++ gets an install_name of /usr/lib when built as a system
library, which means that we must override the copy of libc++ used by
the whole process. This effectively reverts 2cf2f1b, which was the wrong
solution for the problem I was having.
Of course, this assumes that the just-built libc++ is sufficient to
replace the system library, which is not actually the case
out-of-the-box. Indeed, the system library contains a few symbols that
are not provided by the upstream library, leading to undefined symbols
when replacing the system library by the just-built one.
To solve this problem, we separately build shims that provide those
missing symbols and we manually link against them when we build
executables in the tests. While this is somewhat brittle, it provides a
localized and unintrusive way to allow testing the Apple system
configuration in an upstream environment, which has been a frequent
request.
This patch makes a few adjustments to the way we run the tests in the
Apple configuration on macOS:
First, we stop using DYLD_LIBRARY_PATH. Using that environment variable
leads to libc++.dylib being replaced by the just-built one for the whole
process, and that assumes compatibility between the system-provided
dylib and the just-built one. Unfortunately, that is not the case
anymore due to typed allocation, which is only available in the system
one. Instead, we want to layer the just-built libc++ on top of the
system-provided one, which seems to be what happens when we set a rpath
instead.
Second, add a missing XFAIL for a std::print test that didn't work as
expected when building with availability annotations enabled. When we
enable these annotations, std::print falls back to a non-unicode and
non-terminal output, which breaks the test.
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
libc++abi should be responsible for installing its own headers, it
doesn't make sense for libc++ to be responsible for it.
Differential Revision: https://reviews.llvm.org/D101458
This patch upstreams some changes we've made internally to how we're
building the libc++ dylib on Apple platforms. The goal is still to
eventually get rid of `apple-install-libcxx.sh` entirely and have a
proper way to mirror what we do internally with just the normal CMake
configuration.
Differential Revision: https://reviews.llvm.org/D118912
I came across an issue where since we build the library for Apple with
the install name directory being /usr/lib, which means that if we don't
run the tests with DYLD_LIBRARY_PATH, we'll end up loading the
system-provided libc++abi when running the tests. That wreaks havoc.
Instead of fixing it in the legacy config file, this commit introduces
an Apple libc++abi config file that does the right thing.
Differential Revision: https://reviews.llvm.org/D111279
It is not used anywhere anymore since we're using the new runtimes build
in <monorepo>/runtimes now, so we can remove all traces of this build.
Differential Revision: https://reviews.llvm.org/D111351
Apple's libc++ has a few differences with the LLVM libc++, and it is
necessary to use a custom configuration file to test it properly.
Differential Revision: https://reviews.llvm.org/D110777
Since we're using an empty top-level CMakeLists.txt instead of the CMakeLists.txt
inside llvm/, we don't need to specify LLVM_INCLUDE_BENCHMARKS anymore.
