We would like to use clang-scan-deps in Fuchsia build so include it
in the toolchain distribution.
Differential Revision: https://reviews.llvm.org/D72113
Added two confguration argument to provide a host name and SSH user name
to run the tests on the remote target host.
* REMOTE_TEST_HOST - remote host name or address.
* REMOTE_TEST_USER - passwordless SSH account name.
Differential Revision: https://reviews.llvm.org/D71625
We don't have a full sysroot yet, so for now we only include compiler
support and compiler-rt builtins, the rest of the runtimes will get
enabled later.
Differential Revision: https://reviews.llvm.org/D70477
This includes several changes to our toolchain build:
- Switch from RelWithDebInfo to Release as we don't currently use the
debug info and therefore don't need to produce it.
- Disable unwind tables since we don't need them.
- Disable Clang static analyzer and ARCMT since we don't use it.
- Disable Go tests since we don't distribute Go bindings.
- Set the deployment target for macOS to 10.7 to make the toolchain
usable on older systems.
- Restrict the targets we build runtimes for on Darwin only the ones
we actually need.
- Drop llc and opt from the distribution since we don't need them.
Differential Revision: https://reviews.llvm.org/D69415
Undoes some of the effects of r360946 when using the Xcode CMake
generator---it doesn't handle object libraries correctly at all.
Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't
actually test it. Should have no effect on non-Xcode generators.
https://reviews.llvm.org/D68430
llvm-svn: 373769
Using noexcept multilib with -fno-exceptions can lead to significant
space savings when statically linking libc++abi because we don't need
all the unwinding and demangling code.
When compiling with ASan, we already get a lot of overhead from the
instrumentation itself, when statically linking libc++abi, that overhead
is even larger.
Having the noexcept variant for ASan can help significantly, we've seen
more than 50% size reduction in our system image, which offsets the cost
of having to build another multilib.
Differential Revision: https://reviews.llvm.org/D64140
llvm-svn: 365994
Summary:
This will simplify the macros by allowing us to remove the hard-coded
list of libraries that should be installed when
LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
Reviewers: beanz, smeenai
Reviewed By: beanz
Subscribers: aheejin, mehdi_amini, mgorny, steven_wu, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D64580
llvm-svn: 365902
We want to preserve debug info in our runtimes to aid symbolization and
debugging; for shared libraries this will be stripped away during
install-stripped step and distributed via .build-id, for static archives
it's part of the archive and it's a responsibility of the consumer to
strip it away in the final binary if not needed.
Differential Revision: https://reviews.llvm.org/D64605
llvm-svn: 365845
Summary:
In DistributionExample.cmake be sure we use a LTO
capable linker, the easiest to choose is lld.
Reviewers: beanz
Reviewed By: beanz
Patch By: winksaville
Subscribers: mgorny, mehdi_amini, inglorion, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62279
llvm-svn: 362624
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
Since we share headers between host and target builds, we need to use
the same version for both.
Differential Revision: https://reviews.llvm.org/D62712
llvm-svn: 362181
Summary: This file was moved to llvm in D54978, r356929, but the old
file was never removed.
Reviewed By: beanz
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62343
llvm-svn: 361663
This ensures that whether the user uses short or cannonical version
of the triple, Clang will still find the runtimes under the cannonical
triple name.
Differential Revision: https://reviews.llvm.org/D52132
llvm-svn: 361456
llvm_add_library ignores `BUILD_SHARED_LIBS` `STATIC` is explicitly specified. This restores the `BUILD_SHARED_LIBS` behavior to the clang build.
llvm-svn: 361271
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.
This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.
llvm-svn: 360985
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.
This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.
Reviewers: tstellar, winksaville
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61909
llvm-svn: 360946
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
A bunch of macros use the same variable name, and since CMake macros
don't get their own scope, the value persists across macro invocations,
and we can end up exporting targets which shouldn't be exported. Clear
the variable before each use to avoid this.
Converting these macros to functions would also help, since it would
avoid the variable leaking into its parent scope, and that's something I
plan to follow up with. It won't fully address the problem, however,
since functions still inherit variables from their parent scopes, so if
someone in the parent scope just happened to use the same variable name
we'd still have the same issue.
llvm-svn: 357036
We want to distribute only a single archive so -lc++ does the right
thing and users don't have to explicitly link -lc++abi and -lunwind.
Differential Revision: https://reviews.llvm.org/D59803
llvm-svn: 356970
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
When using the umbrella llvm-libraries and clang-libraries targets, we
should export all library targets, otherwise they'll be part of our
distribution but not usable from the CMake package.
Differential Revision: https://reviews.llvm.org/D58862
llvm-svn: 355354
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
r344555 switched LLVM to guarding install targets with LLVM_ENABLE_IDE
instead of CMAKE_CONFIGURATION_TYPES, which expresses the intent more
directly and can be overridden by a user. Make the corresponding change
in clang. LLVM_ENABLE_IDE is computed by HandleLLVMOptions, so it should
be available for both standalone and integrated builds.
Differential Revision: https://reviews.llvm.org/D58284
llvm-svn: 354525
This is modeled after the existing llvm-libraries target. It's a
convenient way to include all clang libraries in a distribution.
This differs slightly from the llvm-libraries target in that it adds any
library added via add_clang_library, whereas llvm-libraries only
includes targets added via add_llvm_library that didn't use the MODULE
or BUILDTREE_ONLY arguments. add_clang_library doesn't appear to have
any equivalents of those arguments, so the conditions don't apply.
Differential Revision: https://reviews.llvm.org/D58269
llvm-svn: 354141
I don't see a reason for these to not have install targets created,
which in turn allows them to be bundled in distributions. This doesn't
affect the "install" target, since that just runs all CMake install
rules (and we were already creating install rules for these).
Differential Revision: https://reviews.llvm.org/D58268
llvm-svn: 354140
In addition to libc++abi and libc++, we also want to use hermetic
static libunwind on Fuchsia.
Differential Revision: https://reviews.llvm.org/D57431
llvm-svn: 352584
-DNDEBUG is no longer needed now that we don't enable assertions,
modules should improve build times for the second stage.
Differential Revision: https://reviews.llvm.org/D56972
llvm-svn: 351709
This reorders options between the first and second stage builds to make
them better lined up. The change also re-enables tests for first stage
which is useful e.g. for cross-compiling when we cannot run tests for
second stage directly (i.e. without emulation).
Differential Revision: https://reviews.llvm.org/D56652
llvm-svn: 351145
This enables x86 relaxation by default. This depends on a linker new
enough to support the new reloc types but since we default to lld we
don't worry about host system linkers that might be too old to support
the new reloc types.
Differential Revision: https://reviews.llvm.org/D56349
llvm-svn: 350460
When cross-compiling the second stage to a different target, we need to
make sure that the first-stage compiler can produce binaries for that
target. Using lld and llvm-objcopy as the default linker and objcopy
tool eliminates some of the dependencies on the host toolchain.
Differential Revision: https://reviews.llvm.org/D54655
llvm-svn: 347108
When second stage is being cross-compiled for a different platform
we need to build enough of first stage runtimes to get a working
compiler.
Differential Revision: https://reviews.llvm.org/D54463
llvm-svn: 347026
Not all Linux targets use the ${arch}-linux-gnu spelling, so instead
specify the list of Linux explicitly.
Differential Revision: https://reviews.llvm.org/D54598
llvm-svn: 346997
We set lld as the default linker on non-Darwin platforms, but we still
need to set -fuse-ld=lld explicitly in to support cross-compiling Linux
runtimes on Darwin.
Differential Revision: https://reviews.llvm.org/D54026
llvm-svn: 346056
This allows building Linux runtimes on any platform if the correct
sysroot is provided via CMake option.
Differential Revision: https://reviews.llvm.org/D53970
llvm-svn: 345889
Now that libc++ uses __exclude_from_explicit_instantiation__ attribute,
this is no longer needed.
Differential Revision: https://reviews.llvm.org/D53839
llvm-svn: 345552
This enables the driver support for direct split DWARF emission for
Fuchsia in addition to Linux.
Differential Revision: https://reviews.llvm.org/D53248
llvm-svn: 344556
Summary:
Enhanced support for Z3 in the cmake configuration of clang; now it is possible to specify any arbitrary Z3 install prefix (CLANG_ANALYZER_Z3_PREFIX) to cmake with lib (or bin) and include folders. Before the patch only in cmake default locations
were searched (https://cmake.org/cmake/help/v3.4/command/find_path.html).
Specifying any CLANG_ANALYZER_Z3_PREFIX will force also CLANG_ANALYZER_BUILD_Z3 to ON.
Removed also Z3 4.5 version requirement since it was not checked, and now Clang works with Z3 4.7
Reviewers: NoQ, george.karpenkov, mikhail.ramalho
Reviewed By: george.karpenkov
Subscribers: rnkovacs, NoQ, esteffin, george.karpenkov, delcypher, ddcc, mgorny, xazax.hun, szepet, a.sidorin, Szelethus
Tags: #clang
Differential Revision: https://reviews.llvm.org/D50818
llvm-svn: 344464
Summary:
clang tools require clang headers to work on real project, e.g. when we
build clangd via `ninja clangd`, we expect the binary can run on
real-world project (without running another command `ninja clang-headers`).
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: mgorny, ilya-biryukov, ioeric, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D52714
llvm-svn: 343459
This is a workaround for PR39053 which was uncovered by D50652 when
the default attribute has been changed from internal_linkage to
always_inline.
Differential Revision: https://reviews.llvm.org/D52402
llvm-svn: 342833
When building libc++ for Fuchsia, we want to distribute shared libc++,
libc++abi and libunwind as separate libraries, but for static versions
we would like to link all of them into libc++ so -lc++ flag has the same
effect whether shared or static library is being used.
Differential Revision: https://reviews.llvm.org/D49628
llvm-svn: 337877
When building runtimes for Linux as part of Fuchsia toolchain, use
libc++ and compiler-rt for sanitizers.
Differential Revision: https://reviews.llvm.org/D49331
llvm-svn: 337117
This is currently breaking because Linux target sysroots rely on
case sensitive filesystem which is not by default enabled on macOS.
Differential Revision: https://reviews.llvm.org/D48710
llvm-svn: 335919
First stage build is only a minimal build where we don't need
a complete multiarch support, but we need enough to build the
second stage.
Differential Revision: https://reviews.llvm.org/D48707
llvm-svn: 335917
Previously we were using default logic when building Linux runtimes
in Fuchsia toolchain, but that leads to various issues due to how
the CMake logic in compiler-rt for determining the platform support
is implemented. With this change, we will use explicit target for
every provided Linux sysroot.
Differential Revision: https://reviews.llvm.org/D48563
llvm-svn: 335812
Now that the structure of Fuchsia SDK has been formalized, we no
longer need to pass all the different CFLAGS/LDFLAGS to the CMake
build separately, we can simply set the FUCHSIA_SDK variable and
derive all the necessary variables from that one inside the cache
file.
Differential Revision: https://reviews.llvm.org/D48564
llvm-svn: 335708
We want to build the second stage compiler with libc++ and compiler-rt,
also include builtins and runtimes into extra bootstrap components to
ensure these get built.
Differential Revision: https://reviews.llvm.org/D47356
llvm-svn: 334445
This enables the use of install-distribution-stripped target in the
2-stage builds.
Differential Revision: https://reviews.llvm.org/D47758
llvm-svn: 334063
This doesn't make any difference since we don't use RPATH/RUNPATH
on Fuchsia but it avoids the CMake error when re-linking libraries
while building with Ninja.
Differntial Revision: https://reviews.llvm.org/D46610
llvm-svn: 331833
This allows passing additional CMake flags to builtins and runtimes
build through Fuchsia cache files.
Differential Revision: https://reviews.llvm.org/D45997
llvm-svn: 331717
This changes some aspects of the build that are not relevant or useful
for Fuchsia like setting the RPATH/RUNPATH.
Differential Revision: https://reviews.llvm.org/D46361
llvm-svn: 331425
This is necessary in order to get a working C++ compiler on Darwin
since Clang expects libc++ headers to be part of the toolchain.
Differential Revision: https://reviews.llvm.org/D46075
llvm-svn: 330855
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
The Clang driver doesn't currently know how to use the libraries
that are shipped as part of the toolchain so there's no reason to
ship them at all.
Differential Revision: https://reviews.llvm.org/D44724
llvm-svn: 328114
Fuchsia already defaults to libc++ and compiler-rt, but we want to use
these as default runtimes even on the host platform.
Differential Revision: https://reviews.llvm.org/D39930
llvm-svn: 327860
Now that almost all functionality of Apple's dsymutil has been
upstreamed, the open source variant can be used as a drop in
replacement. Hence we feel it's no longer necessary to have the llvm
prefix.
Differential revision: https://reviews.llvm.org/D44527
llvm-svn: 327790
libClang is used by other Clang based tools such as cquery while
clang-include-fixer is generally a useful tool.
Differential Revision: https://reviews.llvm.org/D43404
llvm-svn: 325665
Gabor Horvath