Commit Graph

139 Commits

Author SHA1 Message Date
Louis Dionne 48e4b0fd3a [runtimes] Revert the libc++ __config_site change
This is a massive revert of the following commits (from most revent to oldest):

	2b9b7b5775.
	529ac33197
	28270234f1
	69c2087283
	b5aa67446e
	5d796645d6

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.
2020-10-23 09:41:48 -04:00
Louis Dionne 69c2087283 [libc++] Fix compiler-rt build by copying libc++ headers to <build>/include
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.
2020-10-21 16:56:33 -04:00
Dominik Montada 8c03fdf34a [libcxxabi,libunwind] support running tests in standalone mode
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
2020-10-14 09:10:20 +02:00
Louis Dionne d275da17e4 [libc++] Fix eager generator expression in DefineLinkerScript
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.
2020-07-31 11:20:19 -04:00
Louis Dionne 0a00a7d577 [libc++] Use generator expression in Linker script generation
This is an alternative to the workaround in 34a3b24a90.

Differential Revision: https://reviews.llvm.org/D68880
2020-07-30 11:59:29 -04:00
Louis Dionne efa40eb194 [libc++] Use a proper CMake target to represent libc++ headers
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
2020-07-14 09:52:58 -04:00
Louis Dionne da940b1a2d [libc++] Enable tests and documentation by default when building standalone
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.
2020-06-29 12:40:07 -04:00
Louis Dionne 09943e8de1 [libc++] Provide a default LLVM_PATH when building standalone
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.
2020-06-29 12:40:07 -04:00
Louis Dionne 8bc62db272 [libc++] Remove support for building through llvm-config
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.
2020-06-26 15:13:04 -04:00
Louis Dionne 53623d4aa7 [libc++] Always generate a __config_site header
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
2020-06-26 00:47:48 -04:00
Alex Richardson 7142fef03d [libc++] Don't override LIBCXX_CXX_ABI_INCLUDE_PATHS for libcxxrt
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
2020-06-18 18:09:22 +01:00
Louis Dionne e0184357fc [libc++] Link against libatomic when it is found
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
2020-06-05 09:28:44 -04:00
Louis Dionne 9ff51bf92e [libc++] NFC: fix typos 2020-05-01 13:10:30 -04:00
Louis Dionne b4b7c989d6 [libc++] Remove support for specifying LIBCXX_CXX_ABI_SYSTEM manually
This was only kept until Chromium fixed their build of libc++, which
they have now done according to
	https://bugs.chromium.org/p/chromium/issues/detail?id=1067216
2020-04-03 14:11:11 -04:00
Louis Dionne f5c1d4409e [libc++] Try to fix Chromium's build
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.
2020-04-02 13:15:30 -04:00
Louis Dionne 322b53239d [libc++] Attempt to fix the 'runtimes' build
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.
2020-04-02 12:14:13 -04:00
Raul Tambre bcaa01752f [libc++] Fix linking libc++abi in standalone builds
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
2020-04-02 09:36:33 -04:00
Louis Dionne 61e89737c5 [libc++] Simplify the configuration of the C++ ABI library
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!).
2020-04-02 02:21:15 -04:00
Sergej Jaskiewicz ed77efeff1 [libc++] [cmake] Better diagnostics for missing abi library headers
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
2020-03-11 21:02:45 +03:00
Petr Hosek 34a3b24a90 [libc++] Fix linker script generation
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
2019-10-11 04:54:35 +00:00
Louis Dionne fe53d2dc6b [libc++] Workaround old versions of CMake that don't understand list(JOIN)
llvm-svn: 374120
2019-10-08 21:33:35 +00:00
Louis Dionne 1ea8bb39b9 [libc++] Move the linker script generation step to CMake
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
2019-10-08 21:10:20 +00:00
Louis Dionne 5a14c17221 Provide a meaningful diagnostic when LLVM_PATH doesn't point to a directory
llvm-svn: 369312
2019-08-19 23:51:26 +00:00
Louis Dionne 80ef2f05d8 Revert "[libc++] Take 3: Do not cleverly link against libc++abi just because it happens to be there"
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
2019-08-08 00:28:06 +00:00
Louis Dionne e0eed65e06 [libc++] Take 3: Do not cleverly link against libc++abi just because it happens to be there
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
2019-08-07 21:36:03 +00:00
Vitaly Buka a9d5c186e2 Revert "[libc++] Take 2: Do not cleverly link against libc++abi just because it happens to be there"
r365326 still breaks bots:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/20712/steps/ninja%20build%20local/logs/stdio
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/39477/steps/test%20tsan%20in%20debug%20compiler-rt%20build/logs/stdio

And probably others

This reverts commit 945b9ec069.

llvm-svn: 365359
2019-07-08 17:46:23 +00:00
Louis Dionne 945b9ec069 [libc++] Take 2: Do not cleverly link against libc++abi just because it happens to be there
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
2019-07-08 14:49:35 +00:00
Louis Dionne 51de516486 Revert "[libc++] Do not cleverly link against libc++abi just because it happens to be there"
This reverts r365222, which broke the libc++ build bots.

llvm-svn: 365233
2019-07-05 18:44:25 +00:00
Louis Dionne 4ba29e5fbe [libc++] Do not cleverly link against libc++abi just because it happens to be there
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
2019-07-05 17:06:23 +00:00
Brian Cain 9d744bcde9 [libcxx] cmake - guard list remove
REMOVE_ITEM fails if CMAKE_REQUIRED_LIBRARIES is empty on some
versions of cmake.

llvm-svn: 359755
2019-05-02 03:49:50 +00:00
Louis Dionne 68924e6be7 [libc++][CMake] Refactor how we link against system libraries
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

llvm-svn: 359571
2019-04-30 15:44:19 +00:00
Petr Hosek 1788b89b4f [CMake] Split linked libraries for shared and static libc++
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

llvm-svn: 358614
2019-04-17 21:41:09 +00:00
Petr Hosek 30d9af1b24 [CMake] Differentiate between static and shared libc++abi
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

llvm-svn: 357556
2019-04-03 01:33:14 +00:00
Louis Dionne 2d0b4d6bb3 [libc++][CMake] Clean up some of the libc++ re-exporting logic
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

llvm-svn: 356587
2019-03-20 18:16:24 +00:00
Jonas Hahnfeld 66c60d9d71 [compiler-rt] Build custom libcxx with libcxxabi
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
2019-02-17 12:16:20 +00:00
JF Bastien 2df59c5068 Support tests in freestanding
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

llvm-svn: 353086
2019-02-04 20:31:13 +00:00
Michal Gorny d4b194cf95 [cmake] Fix get_llvm_lit_path() to respect LLVM_EXTERNAL_LIT always
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

llvm-svn: 352374
2019-01-28 15:16:03 +00:00
Petr Hosek 2d2e23e89b [CMake] Passthrough CFLAGS when checking the compiler-rt path
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

llvm-svn: 346820
2018-11-14 00:09:26 +00:00
Eric Fiselier 02f8e7c355 Add cxx-benchmark-unittests target
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.

llvm-svn: 346811
2018-11-13 23:08:31 +00:00
Petr Hosek 322d88f05e [CMake] Use just basename when copying C++ ABI headers
This avoids duplicate directories when the filename includes path.

Fixes PR39145

Differential Revision: https://reviews.llvm.org/D52762

llvm-svn: 343753
2018-10-04 05:38:53 +00:00
Eric Fiselier 11edd935c8 Attempt to unbreak Windows configuration.
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.

llvm-svn: 343431
2018-10-01 01:00:11 +00:00
Petr Hosek 9d1bcc2a88 [CMake] Don't install c++abi headers in standalone libc++ build
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

llvm-svn: 337979
2018-07-25 22:57:39 +00:00
Petr Hosek f8f2a788f0 [CMake] Fix the setting of LIBCXX_HEADER_DIR in standalone build
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

llvm-svn: 337833
2018-07-24 15:49:29 +00:00
Petr Hosek 058c04c3dd Reland "[CMake] Support statically linking dependencies only to shared or static library"
This is a reland of commit r337668.

llvm-svn: 337814
2018-07-24 07:06:17 +00:00
Petr Hosek 781ee0bc5a Revert "[CMake] Support statically linking dependencies only to shared or static library"
This reverts commit r337668: broke the cxxabi build when using Make.

llvm-svn: 337670
2018-07-23 05:07:44 +00:00
Petr Hosek 7a0295cbc8 [CMake] Support statically linking dependencies only to shared or static library
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

llvm-svn: 337668
2018-07-23 04:19:55 +00:00
Petr Hosek 32f7fb5713 [CMake] Install C++ ABI headers into the right location
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

llvm-svn: 337630
2018-07-20 22:45:24 +00:00
Petr Hosek 887f26d470 Support for multiarch runtimes layout
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

llvm-svn: 335809
2018-06-28 03:11:52 +00:00
Martin Storsjo 11b02759a3 [CMake] Convert paths to the right form in standalone builds on Windows
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

llvm-svn: 335172
2018-06-20 21:03:34 +00:00
Petr Hosek a9e7908e30 [CMake] Use common variable for all header targets NFC
This simplifies the handling of header targets.

llvm-svn: 334477
2018-06-12 06:58:06 +00:00