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
While the llvm/cmake/platforms/WinMsvc.cmake file only supports
cross-compiles, it contains the right -fms-compatibility-version
to use to build clang/llvm (modulo when upstream forgets to update it).
It's better to rely on that, than to keep a version in build-clang.py
that would possibly need to cover multiple versions of clang.
Differential Revision: https://phabricator.services.mozilla.com/D143133
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
Instead of building compiler-rt alongside clang, we reuse the clang
repack logic to put compiler-rts in place when building clang stage2
(which requires the profiling runtime).
The repack logic is unified to handle all platforms as well, and now
that compiler-rt is not built in clang, we also need to copy everything
that is not lib/* from the compiler-rt artifacts, so we now also ensure
that they're not diverging between those compiler-rt artifacts (except
for darwin libs, which need to be unified into universal libraries).
And as a bonus, we can also cross-build the mac clang toolchains with
the stage1 clang and the clang runtime for the target platform.
Differential Revision: https://phabricator.services.mozilla.com/D138748
This improves out-of-the-box support for cross-compiles on tier-1 build
platforms, including for asan. This also reduces the number of different
*-cross toolchains we need for CI builds.
The linux clang is now also a repack, like the others, and the insertion
of the wasm compiler-rt is moved to the repack, which also allows to
remove that part of the build-clang.py script.
Differential Revision: https://phabricator.services.mozilla.com/D138749
Instead of building compiler-rt alongside clang, we reuse the clang
repack logic to put compiler-rts in place when building clang stage2
(which requires the profiling runtime).
The repack logic is unified to handle all platforms as well, and now
that compiler-rt is not built in clang, we also need to copy everything
that is not lib/* from the compiler-rt artifacts, so we now also ensure
that they're not diverging between those compiler-rt artifacts (except
for darwin libs, which need to be unified into universal libraries).
And as a bonus, we can also cross-build the mac clang toolchains with
the stage1 clang and the clang runtime for the target platform.
Differential Revision: https://phabricator.services.mozilla.com/D138748
The new task builds a stage 2 compiler and uses it to generate the
profile as stage 3, and the profile is used to feed the now separate
stage 4 clang build. This will allow us to use this same profile to
build mac clangs with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D138511
The new task builds a stage 2 compiler and uses it to generate the
profile as stage 3, and the profile is used to feed the now separate
stage 4 clang build. This will allow us to use this same profile to
build mac clangs with PGO.
Differential Revision: https://phabricator.services.mozilla.com/D138511
This means we can now skip building a 32-bit compiler-rt when building
clang itself, as well as the asan pdb files, which will be taken from
the compiler-rt artifact.
Differential Revision: https://phabricator.services.mozilla.com/D137259
Back when this was added, clang's default mode might have been c++11,
but it's not c++17, and we're effectively downgrading it (which
incidentally causes problems to build libc++).
Differential Revision: https://phabricator.services.mozilla.com/D137255
It is currently enabled automatically because libxml2 is detected, but
we want to be sure it's not accidentally disabled.
Differential Revision: https://phabricator.services.mozilla.com/D136840
`extra_targets` was used for the aarch64-linux compiler runtime, which
moved to a separate task in bug 1690757, and `android_targets` was used
for android compiler runtimes, which moved to separate tasks in
bug 1690973.
Using separate tasks is now the prefered way to build compiler runtimes,
os we won't need these options.
Differential Revision: https://phabricator.services.mozilla.com/D136822
When cmake fails during the clang build, we currently print out the
contents of CMakeOutput.log and CMakeError.log because they may contain
something useful to debug what happened. Unfortunately, because the
treeherder log parser doesn't see the actual error, it reports the
normal error that are part of the logs as being the errors causing the
failure, the first one of which is a check whether malloc/malloc.h is a
thing, which it is not, and that's normal.
So instead of printing them out, we provide the files as artifacts.
Differential Revision: https://phabricator.services.mozilla.com/D134999
