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
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. 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
LLVM 11 introduces a hard requirement for SDK 10.12 in order to build for Mac. We want to keep building older LLVMs with 10.11 though, so this patch adds some flexibility so that build-clang can make use of whatever SDK package a particular task pulls from tooltool (but still requesting a deployment target of 10.11).
Differential Revision: https://phabricator.services.mozilla.com/D82621
clang/LLVM's build scripts can turn these on on their own, but explicitly
setting what we want is better than guessing. The change is not huge, maybe
~2-3% on the major shared libraries (`libclang`, `libclang-cpp`, `libLLVM`),
about 1% on the overall `.tar.zst` size, but every little bit counts, right?
Differential Revision: https://phabricator.services.mozilla.com/D82896
Source history does not give any good clues about why this line was added in the first place. In any case, LLVM trunk currently has build bustage when threads are disabled. We could work around the bustage and/or wait for a fix, but it seems like threads are a good thing to have in general nowadays. Maybe this could help with LTO build times.
Differential Revision: https://phabricator.services.mozilla.com/D82447
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
This is required for llvm-mt, which building winchecksec will require.
We do a dummy change to build-clang.sh so as to change the toolchain
index hash.
Differential Revision: https://phabricator.services.mozilla.com/D68153
Best as I can tell, this was a longstanding typo. This went unnoticed because cmake didn't do any interesting `find`s -- until recently in LLVM 10, where zlib is now queried via `find_package`.
Differential Revision: https://phabricator.services.mozilla.com/D62829
