Commit Graph

167 Commits

Author SHA1 Message Date
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 6f69318c72 [runtimes] Allow passing Lit parameters through CMake
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.

This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
2020-07-09 12:45:00 -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 d9dec697cb [libc++][CMake] Add CMake caches for commonly supported configurations
This commit adds CMake caches for the various configurations of libc++
that are tested by our build bots.

Differential Revision: https://reviews.llvm.org/D81293
2020-06-09 14:52:14 -04: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 d0fcdcd28f [libc++] Fix the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT setting
When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined
to 0, which was the NonUnique RTTI comparison implementation. The intent
was to use the Unique RTTI comparison implementation in that case, which
caused https://llvm.org/PR45549.

Instead, use a proper "switch" to select the RTTI comparison implementation.
Note that 0 can't be used as a value, because that is treated the same
by CMake as a variable that is just not defined.

Differential Revision: https://reviews.llvm.org/D80037
2020-05-29 06:14:30 -04:00
Louis Dionne 9ff51bf92e [libc++] NFC: fix typos 2020-05-01 13:10:30 -04:00
Shoaib Meenai cc259638cb [libcxx][libcxxabi][libunwind] Use libgcc on Android
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.

Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines

Differential Revision: https://reviews.llvm.org/D78787
2020-04-30 15:42:32 -07:00
Louis Dionne 2464d8135e [libc++] Make sure we assume merged typeinfo names on Apple
The introduction of LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT changed
the default from =1 (assuming merged typeinfos) to =0 (not assuming
merged typeinfos) on all platforms where at least one other __config_site
macro is defined.

This commit explicitly enables the assumption of merged typeinfo names
on Apple platform to restore the previous behavior, at least until the
underlying issue has been fixed.
2020-04-22 17:35:30 -04:00
Louis Dionne e5291c4ae3 [libc++/abi] Provide an option to turn on forgiving dynamic_cast when building libc++abi
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.

Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
2020-04-22 16:24:26 -04:00
Louis Dionne 2d0c9bf55e [libc++] Update the cache for building libc++/libc++abi on Apple 2020-04-22 14:04:50 -04:00
Louis Dionne d632587664 [libc++] Do not enable assertions in the dylib in the Apple cache
It turns out that all this time, we've actually been building without
assertions enabled in the dylib. This commit updates the Apple CMake
cache to make it consistent with reality.
2020-04-21 13:12:03 -04:00
Louis Dionne f3bf25eb66 [libc++] Explicitly specify that we use libc++abi in Apple's cache 2020-04-08 09:04:39 -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
Louis Dionne 93cdd310e1 [libc++] Explicitly specify LIBCXX_ENABLE_SHARED to try and fix CI
Configuring libc++abi with LIBCXX_ENABLE_STATIC=OFF is broken since
https://reviews.llvm.org/D71894, so this patch fixes the issue for
Apple platforms to unblock our CI.
2020-01-29 17:29:43 -08:00
Petr Hosek 1aa1702381 [libcxx{,abi}] Don't link libpthread and libdl on Fuchsia
These are a part of the libc so linking these explicitly isn't necessary
and embedding these as deplibs causes link time error.

This issues was introduced in a9b5fff which changed how we emit deplibs.

Differential Revision: https://reviews.llvm.org/D71135
2019-12-06 11:15:15 -08: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 340b725202 [libc++] Add a CMake cache for Apple-specific configuration options
llvm-svn: 371638
2019-09-11 16:57:19 +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
Petr Hosek 0528726a69 [libcxx][libcxxabi] Remove the unused CMake checks
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

llvm-svn: 362058
2019-05-30 06:08:56 +00:00
Petr Hosek f1ddf431b5 [runtimes] Use -Wunknown-pragmas for the pragma check
This is a follow up to r362055, we need -Wunknown-pragmas otherwise
the check is going to succeed it the pragma isn't supported.

llvm-svn: 362057
2019-05-30 05:38:06 +00:00
Petr Hosek 789b7f0828 [runtimes] Check if pragma comment(lib, ...) is supported first
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.

llvm-svn: 362055
2019-05-30 04:40:21 +00:00
Louis Dionne 223ed705d0 [libc++][CMake] Link against libSystem on Apple platforms
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.

llvm-svn: 359808
2019-05-02 17:43:48 +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
Petr Hosek 12f4b86808 Revert "[CMake] Use __libc_start_main rather than fopen when checking for C library"
This reverts commit r352341: it broke the build on macOS which doesn't
seem to provide __libc_start_main in its C library.

llvm-svn: 352411
2019-01-28 19:26:41 +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 b667153cf6 [CMake] Use __libc_start_main rather than fopen when checking for C library
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

llvm-svn: 352341
2019-01-28 04:12:54 +00:00