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
- stage 1 is building clang with whatever compiler is available
- stage 2 is building clang with the clang built during stage 1
- stage 3 is building clang with the clang built during stage 2. It's
only useful when it's actively compared against stage 2, or when
there's a stage 4.
- stage 4 is building clang with the clang built during stage 3, with the
profile generated during stage 3, when stage 2 produced a clang with
instrumentation enabled.
We're not actively comparing the output of stage 2 and 3 when not doing
PGO, so it's not useful to do 3-stage builds.
Differential Revision: https://phabricator.services.mozilla.com/D133314
Short of solving this by fully embracing the monorepo build and removing
the projects/ workarounds (which will also require a compat more with
older clang versions we still build with the same script), we can solve
the bustage with a small hack.
Differential Revision: https://phabricator.services.mozilla.com/D131458
Using the sysroot with GCC requires some unnecessary complication, and
we don't really care if the first stages are not using the sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D125161
Building sanitizers in older versions of clang emit errors when built with
newer GCC because of some narrowing conversions. We only really need the
sanitizers in the final stage anyways, so we force-disable them (and
everything else that might enable "sanitizer-common") in early stages.
Building the lli tool (also used in tests) fails as well, and we don't
need it until the final stage (where we need it to ship it).
Differential Revision: https://phabricator.services.mozilla.com/D125159
It's an unnecessary difference with our other clang builds. It looks
like it was cargo-culted from some external script. It makes the
android-cross clang different in the way it finds e.g. compiler
runtimes, some of which are in lib/, and others in lib64/, and only the
latter are actually found.
Differential Revision: https://phabricator.services.mozilla.com/D123017
The wasi-sysroot toolchain contains both a sysroot for wasi and a
compiler-rt for clang. That makes it impractical to use as a
bootstrapped sysroot for wasm32-wasi builds of Spidermonkey.
We thus split the toolchain in two, one for the compiler-rt and one
for the sysroot. Ideally, the compiler-rt one would avoid building
clang/llvm the same way the sysroot one does, but that leads to
a case of chicken-and-egg, because the compiler-rt is needed to build
the clang toolchain. Eventually, the clang build would be split from
the addition of the compiler-rt, but we're not there yet.
Differential Revision: https://phabricator.services.mozilla.com/D122402
Clang >= 11 ignores PYTHON_EXECUTABLE entirely (and uses python3, which
is not even what we pass, but that's actually fine), and all the build
tasks we have on older versions find the python executable they need on
their own.
Differential Revision: https://phabricator.services.mozilla.com/D120049
- we needed -gcc-toolchain to pick C/C++ standard headers from the right
version of GCC, but we now have them in the toolchain sysroot (bug
1719207), so we can use that instead.
- we needed LD_LIBRARY_PATH when clang was built on an older version of
Debian, but that was changed in bug 1694775.
Differential Revision: https://phabricator.services.mozilla.com/D119135
We have a separate binutils toolchain already, and the only remaining
use of the binutils part of the the GCC toolchain is for the gold plugin
headers for clang, which we can add to the toolchain sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D119133
We've been building clang with SDK 10.12 since bug 1680152, but the
build-clang script is still assuming we're building with an older one.
Differential Revision: https://phabricator.services.mozilla.com/D105266
When using the --sysroot argument to clang, clang changes where it
searches for libraries in its own directory, and excludes the lib and
lib32 subdirectories. So we need to move the gcc files to a place where
it does look (and that it also looks without --sysroot).
We however still keep a copy of libstdc++ in the lib directory for
runtime purposes.
Differential Revision: https://phabricator.services.mozilla.com/D104123
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
