There are some cmake flags we currently only set for mac cross compiles,
but would be just as good to always set and/or for all cross compiles.
The former is the case for CMAKE_*_COMPILER_TARGET.
The latter it the case for CMAKE_SYSTEM_NAME, which implies
CMAKE_CROSSCOMPILING.
LLVM_DEFAULT_TARGET_TRIPLE is implied by LLVM_HOST_TRIPLE, which is
also more important to set, so we set that one instead.
While touching build-clang.py, we also add aarch64-unknown-linux-gnu
as a supported cross-compilation target without adding the corresponding
toolchain. This will avoid rebuilding all the compilers when just adding
new configs for arm64 linux clang toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D232441
By doing so, we don't really need a stage 1 clang for mac and windows
(with the downside that the final PGOed clang becomes the
clang-toolchain artifact on those platforms), and cross-compiling stage
2 is much faster as a cross-compile, leaving only stage 3 to be native.
While here, for the one build type that still does stage 2 and 3 in one
task, we actually prefer taking the llvm-profdata from stage 1, as it
doesn't contain profile instrumentation (it should actually have been
this way since the beginning).
Differential Revision: https://phabricator.services.mozilla.com/D220654
By doing so, we don't really need a stage 1 clang for mac and windows
(with the downside that the final PGOed clang becomes the
clang-toolchain artifact on those platforms), and cross-compiling stage
2 is much faster as a cross-compile, leaving only stage 3 to be native.
While here, for the one build type that still does stage 2 and 3 in one
task, we actually prefer taking the llvm-profdata from stage 1, as it
doesn't contain profile instrumentation (it should actually have been
this way since the beginning).
Differential Revision: https://phabricator.services.mozilla.com/D220654
This splits the clang build in the necessary steps to get native
profiles for Intel and Arm64 mac, similarly to Linux.
Stage 1s are cross-compiled, and the profile step runs natively.
Differential Revision: https://phabricator.services.mozilla.com/D220530
For now this uses Linux x64 profile for PGO as the macosx64-aarch64 task does, because we don't have aarch64 Windows worker now.
Differential Revision: https://phabricator.services.mozilla.com/D219012
Bug 1805664 had the side effect of installing terminfo libraries on the
toolchain docker image, which led to clang gaining a dependency on
libtinfo, leading to multiple failures, like PGO run jobs failing with
llvm-profdata failing to load the new dependency, or tsan tests failing
because llvm-symbolizer doesn't work because of the new dependency not
being fulfilled, which in turn breaks TSAN suppressions.
Differential Revision: https://phabricator.services.mozilla.com/D170417
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
These flags used to be necessary when we first were cross-compiling
clang, but more recent (although now old) changes have made them
actually unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D168033
Using ThinLTO because it's a good compromise between performance and
compilation speed.
Activating it for both profile generation and profile usage, doing it
only for profile usage leads to a lot of mismatch, aka
function control flow change detected (hash mismatch)
which leads to profile information not beoing used.
This requires using the whole llvm toolchain (lld, llvm-ar, llvm-ranlib)
from the same revision.
This is disabled on Windows where it causes link error on the LLVM
Plugin system.
Differential Revision: https://phabricator.services.mozilla.com/D162371
There are some ABI issues with libc++ headers in clang 15. The main
reason we are shipping libc++ with our clang is that the macos SDK,
up to and including 11.1, only contained the libc++ libraries, but
not the headers. The first SDK that contains the headers is 11.3
(there is no 11.2, at least publicly available), and we're now using
it.
Another problem with libc++ is that the way we currently build it is
deprecated and is going to yields hard errors soon enough on clang
trunk.
The simplest thing to do right now is to just stop shipping libc++.
Eventually, we may want to ship it correctly in a different way, for
all platforms, which was not happening anyways.
Differential Revision: https://phabricator.services.mozilla.com/D156283
Currently, when building clang for mac, which we cross-compile, we're
always passing a x86-64 target, even on arm64. This cancels out with the
LLVM build system adding `-arch arm64`, so it worked fine... until clang
15, where some things end up being built without `-arch arm64` and
things end up broken.
Differential Revision: https://phabricator.services.mozilla.com/D156258
There are a set of problems that arise from that setup that need to be
addressed before this can be enabled, but upstream is toying with it,
and it's better to have a setup that is stable rather than a setup that
can break when upstream changes something (which happened again earlier
today).
Differential Revision: https://phabricator.services.mozilla.com/D148625
Bug 1744890 moved build_libcxx out of the individual json configs, and
bug 1748056 made it always True. We can now remove it.
Differential Revision: https://phabricator.services.mozilla.com/D146873
