When building runtimes, the compiler name (e.g. clang, clang-cl) is set based on
`CMAKE_SYSTEM_NAME` passed to `llvm_ExternalProject_Add()` through `CMAKE_ARGS` argument.
This mechanism doesn't work well if the target is Windows host.
`runtime_default_target()`/`builtin_default_target()` doesn't provide a way
to specify `CMAKE_SYSTEM_NAME` and doesn't set it either.
This patch appends variables specified in `RUNTIMES_CMAKE_ARGS`/`BUILTINS_CMAKE_ARGS`
to `CMAKE_ARGS` argument of `llvm_ExternalProject_Add()` in the case of called
from `runtime_default_target()`/`builtin_default_target()` thus in particular
it allows passing CMAKE_SYSTEM_NAME whenever it is required.
Reviewed By: phosek, compnerd, plotfi
Differential Revision: https://reviews.llvm.org/D81877
No need to parse and add the same variables twice if runtimes is being
built for a generic target (i.e. w/o multilib).
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D81574
Currently we passthrough CMake variables based on project prefix,
i.e. LIBCXX_, LIBCXXABI_, LIBUNWIND_ and COMPILER_RT_. However, many
compiler-rt flags start with SANITIZER_ rather than COMPILER_RT, so
passthrough those as well.
Differential Revision: https://reviews.llvm.org/D75773
This will create e.g. a compiler-rt target that'll build compiler-rt for
all configured targets, similar to how the runtimes umbrella target
builds all the runtimes for all configured targets.
Differential Revision: https://reviews.llvm.org/D74458
These don't build on MSVC at the moment, so filter these out altogether
from the list of runtimes and print a warning.
Differential Revision: https://reviews.llvm.org/D73812
When building the default builtin and runtimes target, set the
CMAKE_SYSTEM_NAME to the current one. This is not necessary on
Linux and Darwin, but it appears to be necessary on Windows,
otherwise CMake fails.
Differential Revision: https://reviews.llvm.org/D73811
I missed the NOT in the condition; this part is actually responsible for
passing LLVM_ENABLE_RUNTIMES to the per-target runtime configures, which
in turn makes them actually build.
I'll put up a more general solution for review, but restore this in the
meantime to fix the runtimes build.
We have to replace the ";" with "|" (since LLVMExternalProjectUtils uses
"|" as the `LIST_SEPARATOR` when invoking `ExternalProject_Add`) in
order for lists to be passed correctly to the runtimes CMake configures.
Remove the special case for `LLVM_ENABLE_RUNTIMES`, since it'll just get
handled by the general logic now.
Differential Revision: https://reviews.llvm.org/D73512
The installation target we create should trigger the corresponding
installation target in the runtimes external project.
Differential Revision: https://reviews.llvm.org/D73251
Runtimes variables in a multi-target environment are defined like:
RUNTIMES_target_VARIABLE_NAME
RUNTIMES_target+multi_VARIABLE_NAME
In my case, I have a downstream runtimes cache that does the following:
set(RUNTIMES_${target}+except_LIBCXXABI_ENABLE_EXCEPTIONS ON CACHE BOOL "")
set(RUNTIMES_${target}_LIBCXX_ENABLE_EXCEPTIONS OFF CACHE BOOL "")
I found that I was always getting the 'target' variable value (OFF) in
my 'target+except' build, which was unexpected. This behavior was
caused by the loop in llvm/runtimes/CMakeLists.txt that runs through all
variable names, adding '-DVARIABLE_NAME=' options to the subsequent
external project's cmake command.
The issue is that the loop does a single pass, such that if the 'target'
value appears in the cache after the 'target+except' value, the 'target'
value will take precedence. I suggest in my change here that the more
specific 'target+except' value should take precedence always, without
relying on CMake cache ordering.
Differential Revision: https://reviews.llvm.org/D71570
Patch By: JamesNagurne
Summary: With the new LLVM_ENABLE_RUNTIMES option introduced in https://reviews.llvm.org/D40233, compiler-rt can now be included as a runtime. Since compiler-rt is needed for PGO, runtimes needs to be included as a dependency of clang-bootstrap-deps when building the stage1 compiler.
Reviewers: beanz, phosek, compnerd, smeenai, plotfi, xiaobai
Reviewed By: phosek
Subscribers: smeenai, beanz, phosek, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71430
Summary: Currently, llvm-lipo is not specified as a dependency, but it is needed when building Darwin-x86_64 runtimes, so I'm adding it to the dependencies lists.
Reviewers: alexshap, beanz, phosek, compnerd, smeenai, mtrent, plotfi, xiaobai
Reviewed By: phosek, smeenai
Subscribers: smeenai, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71429
Second attempt: Now with ';' -> '|' replacement.
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
Differential Revision: https://reviews.llvm.org/D67195
llvm-svn: 372784
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
Differential Revision: https://reviews.llvm.org/D67195
llvm-svn: 371566
Summary: The default runtimes targets aren't getting their dependencies configured correctly which results in check-runtimes failing when built from a clean build.
Reviewers: phosek, compnerd
Reviewed By: phosek
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63107
llvm-svn: 363015
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Differential Revision: https://reviews.llvm.org/D62769
llvm-svn: 362313
CMake always uses absolute file paths in the generated compiler
invocation which results in absolute file paths being embedded in debug
info. This is undesirable when building a toolchain e.g. on bots as the
debug info may embed the bot source checkout path which is meaningless
anywhere else.
This change introduces the LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO which uses
-fdebug-prefix-map (where supported) options to rewrite paths embedded
into debug info with relative ones. Additionally, LLVM_SOURCE_PREFIX can
be used to override the path to source directory with a different one.
Differential Revision: https://reviews.llvm.org/D62622
llvm-svn: 362185
This avoids using llvm-config for inferring various paths within the
runtimes build. We also set LLVM_INCLUDE_DIR variable that's used by
these builds and move assignment of LLVM_BINARY_DIR and LLVM_LIBRARY_DIR
to the same location for consistency.
Differential Revision: https://reviews.llvm.org/D62637
llvm-svn: 362047
Summary:
The runtimes use `*_STANDALONE_BUILD=OFF` to signify that clang is an in-tree target. This is not the case with the runtime builds, so we really need this set to `ON`.
In order to resolve the issues phosek was having with checks, we should use checks that don't link. We can use compiler-rt's `try_compile_only` as a basis for that.
This patch is *required* to be able to run the runtime libraries check-* targets.
Reviewers: smeenai, phosek, compnerd
Reviewed By: phosek
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62410
llvm-svn: 362007
This resolves two issues:
(1) LIBCXX_HEADER_DIR is a very misleadingly named variable because it shouldn't be set to the header directory, instead it needs to be the root binary dir.
(2) If you build runtimes without libcxx, we can't depend on the libcxx header target, so we should instaed refer to it by the variable name which will be unset if libcxx isn't present.
llvm-svn: 361646
Summary:
I somehow messed this up. libcxx appends the subdirectories itself, so we don't need to add them here.
Also, r361513 broke the "projects" build of libcxx because it always included the extra targets.
Reviewers: lebedev.ri, mclow.lists
Subscribers: mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62336
llvm-svn: 361535
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Reviewers: phosek, compnerd, smeenai, EricWF
Reviewed By: compnerd
Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits
Tags: #llvm, #libc
Differential Revision: https://reviews.llvm.org/D62155
llvm-svn: 361513
Summary: If we are building the tests for the runtimes we should make them depend on gtest so that gtest is built and ready before we run any of the check-* targets.
Reviewers: phosek, compnerd
Reviewed By: compnerd
Subscribers: mgorny, winksaville, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62269
llvm-svn: 361436
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/$target/c++ and include/c++ directories, leaving resource directory
only for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59168
llvm-svn: 361432
This is a more generic solution; while the sanitizer support can be used
only for sanitizer instrumented builds, the multilib support can be used
to build other variants such as noexcept which is what we would like to use
in Fuchsia.
The name CMake target name uses the target name, same as for the regular
runtimes build and the name of the multilib, concatenated with '+'. The
libraries are installed in a subdirectory named after the multilib.
Differential Revision: https://reviews.llvm.org/D60926
llvm-svn: 358935
When installing runtimes with install-runtimes-stripped, we don't want
to just strip them, we also want to preserve the debugging information
for potential debugging. To make it possible to later find the stripped
debugging information, we want to use the .build-id layout:
https://fedoraproject.org/wiki/RolandMcGrath/BuildID#Find_files_by_build_ID
That is, for libfoo.so with build ID abcdef1234, the debugging information
will be installed into lib/debug/.build-id/ab/cdef1234. llvm-objcopy
already has support for stripping files and linking the debugging
stripped output into the right location. However, CMake doesn't support
customizing strip invocation for the *-stripped targets. So instead, we
replace CMAKE_STRIP with a custom script that invokes llvm-objcopy with
the right command line flags.
Differential Revision: https://reviews.llvm.org/D59127
llvm-svn: 355765
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
compiler-rt builtins depend on clang headers, but that dependency
wasn't explicitly stated in the build system and we were relying
on the transitive depenendecy via clang. However, when we're
cross-compiling clang, we'll be using host compiler instead and
that depenendecy is missing, breaking the build.
Differential Revision: https://reviews.llvm.org/D58471
llvm-svn: 354524
Ensure that HandleLLVMOptions adds all necessary required flags,
including -Wno-error when building with LLVM_ENABLE_WERROR enabled.
Differential Revision: https://reviews.llvm.org/D58092
llvm-svn: 353790
We shouldn't be treating runtimes builds as standalone builds since
we have enough of the context loaded into the runtimes environment.
Differential Revision: https://reviews.llvm.org/D57992
llvm-svn: 353601
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
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
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
This is needed when the external projects try to use other tools
besides just the compiler and the linker.
Differential Revision: https://reviews.llvm.org/D47833
llvm-svn: 334136
