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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368213 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365326 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@365222 91177308-0d34-0410-b5e6-96231b3b80d8
These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.
Differential Revision: https://reviews.llvm.org/D62566
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@362058 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow up to r362055, we need -Wunknown-pragmas otherwise
the check is going to succeed it the pragma isn't supported.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@362057 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@362055 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of manually linking against libm/librt/libpthread, we should be
linking against libSystem on Apple platforms, and only that. libm and
libpthread are symlinks to libSystem anyway.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359808 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of populating the global LIBCXX_LIBRARIES, we use the link-time
dependency management built into CMake to propagate link flags. This
leads to a cleaner and easier-to-follow build.
Reviewers: phosek, smeenai, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, jfb, mstorsjo, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60969
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@359571 91177308-0d34-0410-b5e6-96231b3b80d8
Some linker libraries are only needed for shared libc++, some only
for static libc++, combining these together in LIBCXX_LIBRARIES and
LIBCXX_INTERFACE_LIBRARIES can introduce unnecessary dependencies.
This changes splits those up into LIBCXX_SHARED_LIBRARIES and
LIBCXX_STATIC_LIBRARIES matching what libc++abi already does.
Differential Revision: https://reviews.llvm.org/D57872
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@358614 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses the issue introduced in r354212 which broke the case when
static libc++abi is merged into static libc++, but shared libc++ is
linked against shared libc++. There are 4 different possible
combinations which is difficult to capture using a single variable. This
change splits LIBCXX_CXX_ABI_LIBRARY into two:
LIBCXX_CXX_SHARED_ABI_LIBRARY and LIBCXX_CXX_STATIC_ABI_LIBRARY to
handle the shared and static cases. This in turn allows simplification
of some of the logic around merging of static archives.
Differential Revision: https://reviews.llvm.org/D60114
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@357556 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change allows specifying the version of libc++abi's ABI to re-export
when configuring CMake. It also clearly identifies which ABI version of
libc++abi each export file contains.
Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS,
since that knowledge is not relevant anymore. Indeed, libc++ can't be
built with the toolchain that came with the 10.9 SDK anyway because
the version of Clang it includes is too old (for example if you want
to build a working libc++.dylib, you need bugfixes to visibility
attributes that are only in recent Clangs).
Reviewers: dexonsmith, EricWF
Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59489
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@356587 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@354212 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@353086 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r352341: it broke the build on macOS which doesn't
seem to provide __libc_start_main in its C library.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@352411 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@352374 91177308-0d34-0410-b5e6-96231b3b80d8
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@352341 91177308-0d34-0410-b5e6-96231b3b80d8
This is needed when cross-compiling for a different target since
CFLAGS may contain additional flags like -resource-dir which
change the location in which compiler-rt builtins are found.
Differential Revision: https://reviews.llvm.org/D54371
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@346820 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@346811 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@343431 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
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
This is a follow-up to r335809 and r337118. While libc++ headers are now
installed into the right location in both standard as well as multiarch
runtimes layout, turned out C++ ABI headers are still installed into the
old location in the latter case. This change addresses that.
Differential Revision: https://reviews.llvm.org/D49584
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@337630 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
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48356
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@335172 91177308-0d34-0410-b5e6-96231b3b80d8
This resolves the breakage introduced in r334468 which results in
build error when using CMake Makefile generator.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334470 91177308-0d34-0410-b5e6-96231b3b80d8
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@334468 91177308-0d34-0410-b5e6-96231b3b80d8
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329544 91177308-0d34-0410-b5e6-96231b3b80d8
When libcxx is built in tree for a host which requires libatomic, LLVM's
configuration steps will determine it is required and add it to
CMAKE_REQUIRED_LIBRARIES. When libcxx is later configured, it tests if it
has C++ atomics without libatomic. The test erroneously passes as libatomic
is already part of the set of required libraries.
In turn, a number of the atomic tests will fail as they require libatomic
but the test suite is configured not to use libatomic.
Address this by always dropping libatomic from the set of required libraries
before determining if LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB is true,
then restoring the set of required libraries.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D43509
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@329167 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the install command for the cxxabi headers specified
the wrong component, and therefore they were not being included
in the install-cxx command.
This patch corrects the component name.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@318989 91177308-0d34-0410-b5e6-96231b3b80d8
Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@313763 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
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
We're using -nodefaultlibs to avoid the dependency on C++ library
when using check_cxx_compiler_flag, and as such we cannot use
check_cxx_compiler_flag to check the availability of -nodefaultlibs
itself.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@299711 91177308-0d34-0410-b5e6-96231b3b80d8
