Commit Graph

203 Commits

Author SHA1 Message Date
Louis Dionne 2ae52326da [libc++] Towards a simpler extern template story in libc++
The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).

This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.

Differential Revision: https://reviews.llvm.org/D103960
2022-06-08 22:05:07 -04:00
Louis Dionne 851bfc07c8 [libc++abi] Use from-scratch testing configs for libc++abi by default
Like we have been doing for libc++ for a while now, start using
from-scratch testing configurations for libc++abi.

As a fly-by fix, remove the LIBCXXABI_NO_TIMER macro, which was defined
but never used.

Differential Revision: https://reviews.llvm.org/D125242
2022-05-26 09:08:31 -04:00
Louis Dionne fa7ce8e685 [runtimes] Fix the build of merged ABI/unwinder libraries
Also, add a CI job that tests this configuration. The exact configuration
is that we build a shared libc++ and merge objects for the ABI library
and the unwinder library into it.

Differential Revision: https://reviews.llvm.org/D125903
2022-05-19 10:49:36 -04:00
Martin Storsjö bedf657d0f [runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows
(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)

Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library.  If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.

The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.

(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)

This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.

Differential Revision: https://reviews.llvm.org/D125715
2022-05-18 20:31:51 +03:00
Petr Hosek 6f5f847a36 [libcxxabi] Copy headers into build location
Prior to D120727, the libcxx build was responsible for copying libcxxabi
headers into the right location, both in the build and install trees,
but now it's the responsibility of the libcxxabi build. While the build
already did the right thing for the install tree, it wouldn't copy
headers into the build tree, resulting in errors when trying to use the
just built toolchain as is the case in the runtimes build when building
compiler-rt runtimes.

Differential Revision: https://reviews.llvm.org/D125597
2022-05-14 03:49:09 +00:00
Louis Dionne 0a22dfcb11 [runtimes][NFC] Remove dead code for Standalone builds
Standalone builds have been deprecated and then removed for a while now.
Trying to use standalone builds leads to a fatal CMake error, so this
code is all dead. Remove it to clean things up.

Differential Revision: https://reviews.llvm.org/D125561
2022-05-13 14:37:24 -04:00
Louis Dionne c631e33f31 [runtimes] Print the testing configuration in use in libunwind and libc++abi
We do it for libc++, and it's rather useful for debugging e.g. CI.
2022-05-11 10:18:09 -04:00
Petr Hosek b3df14b6c9 [runtimes] [CMake] Unify variable names
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.

Differential Revision: https://reviews.llvm.org/D110005
2022-04-24 13:06:36 +03:00
Louis Dionne f29002a4b7 [libunwind] Add a _LIBUNWIND_VERSION macro
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.

As discussed in https://llvm.org/D119538.

Differential Revision: https://reviews.llvm.org/D121015
2022-03-30 11:23:36 -04:00
Martin Storsjö ebde6fc23b [libcxxabi] Fix cmake order dependency wrt dllexporting
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.

This makes sure that the symbols are properly dllexported in such
a configuration scenario.

Differential Revision: https://reviews.llvm.org/D120982
2022-03-07 15:36:04 -05:00
Louis Dionne 3ee0cec88e [runtimes] Remove FOO_TARGET_TRIPLE, FOO_SYSROOT and FOO_GCC_TOOLCHAIN
Instead, folks can use the equivalent variables provided by CMake
to set those. This removal aims to reduce complexity and potential
for confusion when setting the target triple for building the runtimes,
and make it correct when `CMAKE_OSX_ARCHITECTURES` is used (right now
both `-arch` and `--target=` will end up being passed, which is downright
incorrect).

Differential Revision: https://reviews.llvm.org/D112155
2022-03-01 08:39:42 -05:00
Louis Dionne 6dfdf79b8c [libc++abi] Install the libc++abi headers from libc++abi
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
2022-02-28 17:22:53 -05:00
Louis Dionne 2e3bb910e3 [runtimes] Move warning messages for FOO_SYSROOT & friends above their default value
Otherwise, the warnings always trigger.
2022-02-16 12:00:34 -05:00
Louis Dionne 641a141da1 [runtimes] Deprecate FOO_SYSROOT & friends
As suggested in https://reviews.llvm.org/D112155.

Differential Revision: https://reviews.llvm.org/D119836
2022-02-16 09:44:08 -05:00
Louis Dionne 6f17768e11 [runtimes] Remove support for standalone builds
Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.

This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.

Differential Revision: https://reviews.llvm.org/D119255
2022-02-09 08:55:31 -05:00
John Ericson df31ff1b29 [cmake] Make include(GNUInstallDirs) always below project(..)
Its defaulting logic must go after `project(..)` to work correctly,  but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.

The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.

Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D117639
2022-01-20 18:59:17 +00:00
John Ericson 429a717ea5 [cmake] Move HandleOutOfTreeLLVM to common cmake utils
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
2022-01-19 22:05:23 +00:00
John Ericson f16a4a034a [libcxx][libcxxabi][libunwind][cmake] Use `GNUInstallDirs` to support custom installation dirs
I am breaking apart D99484 so the cause of build failures is easier to
understand.

Differential Revision: https://reviews.llvm.org/D117417
2022-01-18 06:44:57 +00:00
John Ericson da77db58d7 Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have
this odd error, not sure how to reproduce, so I will just try breaking
up my patch.

This reverts commit 4a678f8072.
2022-01-16 05:48:30 +00:00
John Ericson 4a678f8072 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
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
2022-01-16 05:33:07 +00:00
John Ericson 6e52bfe09d Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
Sorry for the disruption, I will try again later.

This reverts commit efeb501970.
2022-01-15 07:35:02 +00:00
John Ericson efeb501970 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
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
2022-01-15 01:08:35 +00:00
Muiez Ahmed a1da73961d [SystemZ][z/OS] ASCII/EBCDIC support with no coexistence
The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch.

Differential Revision: https://reviews.llvm.org/D114813
2022-01-14 11:37:09 -05:00
John Ericson 0a8d15ad55 [libc++][libc++abi][libunwind] Dedup install path var definitions
In D116873 I did this for libunwind prior to defining a new install path
variable. But I think the change is good on its own, and libc++{,abi}
could also use it.

libc++ needed the base header var defined above the conditional part to
use it for the prefi+ed headers in the non-target-specific case. For
consistency, I therefore put the unconditional ones above for all 3
libs, which is why I touched the libunwind code (seeing that it had the
core change already)

Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D116988
2022-01-11 18:24:50 +00:00
John Ericson 949bbd0a68 [CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity
In D116472 we created conditionally defined variables for the tools to
unbreak the legacy build where they are in `llvm/tools`.

The runtimes are not tools, so that flexibility doesn't matter. Still,
it might be nice to define (unconditionally) and use the variable for
the runtimes simply to make the code a bit clearer and document what is
going on.

Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path.

Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D116477
2022-01-03 20:55:44 +00:00
Louis Dionne dc1244dc4e [runtimes] Move WARNING to FATAL_ERROR for folks using FOO_BUILD_32_BITS 2021-12-01 12:57:30 -05:00
Louis Dionne fa1c077b41 [runtimes] Remove support for GCC-style 32 bit multilib builds
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.

As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.

Differential Revision: https://reviews.llvm.org/D114473
2021-12-01 12:57:01 -05:00
Louis Dionne ea23cc7120 [libc++abi] Don't re-define _LIBCPP_HAS_NO_THREADS in single-threaded mode
Libc++ already defines the macro inside its __config_site header, so
libc++abi doesn't need to do it. Doing it just leads to -Wmacro-redefined
warnings when building libc++abi.
2021-11-17 10:59:39 -05:00
David Tenty 2b416b4647 [libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES
and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path.

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 16:04:10 -05:00
Petr Hosek 22acda48ff [CMake] Cache the compiler-rt library search results
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
2021-10-27 17:53:03 -07:00
Petr Hosek ba4920e98e Revert "[CMake] Cache the compiler-rt library search results"
This reverts commit 0eed292fba, there
are compiler-rt build failures that appear to have been introduced
by this change.
2021-10-21 10:32:01 -07:00
Louis Dionne 72117f2ffe [runtimes] Properly handle the sysroot/triple/gcc-toolchain
In 395271a, I simplified how we handled the target triple for the
runtimes. However, in doing so, we stopped considering the default
in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE
(which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified.
This commit fixes that problem and also refactors the code so that it's
easy to see what the default value is.

The fact that nobody seems to have been broken by this makes me think
that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the
triple -- but it should still work.

Differential Revision: https://reviews.llvm.org/D111672
2021-10-21 10:06:11 -04:00
Petr Hosek 0eed292fba [CMake] Cache the compiler-rt library search results
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
2021-10-18 14:44:07 -07:00
Louis Dionne d1e0f02e0b [libc++abi][ci] Add a from-scratch config for libc++abi on Apple/system
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
2021-10-13 08:07:40 -04:00
Louis Dionne 54a8a0d09a [runtimes] Allow FOO_TEST_CONFIG to be a relative path
That makes it possible to store that value in a CMake cache if needed.

Differential Revision: https://reviews.llvm.org/D110843
2021-10-05 19:45:50 -04:00
Martin Storsjö c4e8a2136c [runtimes] Allow overriding where CMake installs RUNTIME type libraries (DLLs)
Differential Revision: https://reviews.llvm.org/D107892
2021-09-09 00:01:38 +03:00
Louis Dionne 395271ad11 [runtimes] Simplify how we set the target triple
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.

This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.

Differential Revision: https://reviews.llvm.org/D106009
2021-07-16 10:33:39 -04:00
Louis Dionne a59165b017 [runtimes] Don't try passing --target flags to GCC
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
2021-07-15 16:52:02 -04:00
Louis Dionne 850b57c5fb [runtimes] Bring back TARGET_TRIPLE
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
2021-07-14 15:15:22 -04:00
Louis Dionne 5099e01568 [runtimes] Inherit the TARGET_TRIPLE that may be set by LLVM 2021-07-14 14:29:29 -04:00
Louis Dionne 77396bbc98 [runtimes] NFCI: Drop intermediate CMake variable TARGET_TRIPLE
We might as well use the various XXX_TARGET_TRIPLE variables directly.
2021-07-14 10:49:28 -04:00
John Ericson 1e03c37b97 Prepare Compiler-RT for GnuInstallDirs, matching libcxx, document all
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.

This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.

One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.

Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).

---

Original message:

Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.

This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.

---

There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.

That last part should be the only behavior changes; everything else
should be a pure refactoring.

---

I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.

[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html

[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options

In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.

---

D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.

Reviewed By: phosek, #libc_abi, #libunwind

Differential Revision: https://reviews.llvm.org/D105765
2021-07-13 15:21:41 +00:00
Louis Dionne a0ae3b0789 [libc++abi] Remove the LIBCXXABI_ENABLE_PIC option
Instead, people should be using CMAKE_POSITION_INDEPENDENT_CODE to control
whether they want to use PIC or not. We should try to avoid reinventing
the wheel whenever CMake natively supports something.

This makes libc++abi consistent with libc++ and libunwind.

Differential Revision: https://reviews.llvm.org/D103973
2021-06-10 12:26:31 -04:00
Shoaib Meenai 6c05f2dab3 [libcxxabi] Remove unnecessary define from build
Now that we're passing -D_LIBCPP_BUILDING_LIBRARY to the libc++abi
build, -D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS is redundant
(fb3a00c327/libcxx/include/exception (L120-L121)
is the only use of _LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS in
libc++, and that conditional also checks for _LIBCPP_BUILDING_LIBRARY).

Reviewed By: #libc_abi, phosek

Differential Revision: https://reviews.llvm.org/D102372
2021-05-20 16:56:05 -07:00
Petr Hosek f749550cfe [libcxx] Stop using use c++ subdirectory for libc++ library
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.

Differential Revision: https://reviews.llvm.org/D100869
2021-04-21 15:39:03 -07:00
Petr Hosek 96d8c6b571 [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX
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
2021-04-01 10:13:07 -07:00
Petr Hosek 1687f2bbe2 [libcxxabi] Use cxx-headers target to consume libcxx headers
Rather than including libc++ include dir, use the cxx-headers target.

Differential Revision: https://reviews.llvm.org/D98367
2021-03-26 13:27:51 -07:00
Petr Hosek 74ed5124ba Revert "[libcxxabi] Use cxx-headers target to consume libcxx headers"
This reverts commit 72728e1280
which broke libcxxabi tests under the runtimes build.
2021-03-25 01:50:11 -07:00
Petr Hosek 72728e1280 [libcxxabi] Use cxx-headers target to consume libcxx headers
Rather than including libc++ include dir, use the cxx-headers target.

Differential Revision: https://reviews.llvm.org/D98367
2021-03-23 12:25:30 -07:00
Markus Böck 05b3716ddb [libcxxabi] Add LIBCXXABI_HAS_WIN32_THREAD_API build option
A few files in libc++abi make use of libc++ headers and a few of those use threading primitives provided by libc++. Since libc++ has multiple threading APIs it may be necessary to override auto-detection.

This patch adds the LIBCXXABI_HAS_WIN32_THREAD_API which does roughly the same as LIBCXXABI_HAS_PTHREAD_API and the similarly named LIBCXX_HAS_WIN32_THREAD_API from libc++. Instead of using autodetection it will force the use of win32 threads instead of pthreads in headers included from libc++.

Without this patch, libc++abi may depend on pthreads if present on the users build environment, even if win32 threading was selected for libc++.

Differential revision: https://reviews.llvm.org/D98021
2021-03-05 15:30:13 +01:00