We need this for "full" C++17 support (everything is supported, but some
C++17 features still have bugs) and this change also brings Linux into
parity with our Mac requirements.
MANUAL PUSH: build toolchains on inbound to avoid clogging autoland
Differential Revision: https://phabricator.services.mozilla.com/D51450
In the future we should re-write this checker but for now this solution is acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D51242
--HG--
extra : moz-landing-system : lando
Since we've upgraded to clang 9, clang-format changed and now uses dynamic libraries
for the clang tooling lib that it leverages.
Differential Revision: https://phabricator.services.mozilla.com/D47265
--HG--
extra : moz-landing-system : lando
This definition is now unnecessary, given that the source code is
fetched for us from elsewhere.
Depends on D41368
Differential Revision: https://phabricator.services.mozilla.com/D41369
--HG--
extra : moz-landing-system : lando
Otherwise we wind up with clownshoes like:
```
froydnj@hawkeye:/opt/build/froydnj/tmp/clang$ ls -l lib/libstdc++.so*
-rwxr-xr-x 1 froydnj froydnj 11633720 Aug 6 20:44 lib/libstdc++.so
-rwxr-xr-x 1 froydnj froydnj 11633720 Aug 6 20:44 lib/libstdc++.so.6
-rwxr-xr-x 1 froydnj froydnj 11633720 Aug 6 20:44 lib/libstdc++.so.6.0.24
```
and have duplicate copies of shared libraries in our toolchain packages,
which are not exactly small.
Differential Revision: https://phabricator.services.mozilla.com/D41368
--HG--
extra : moz-landing-system : lando
What this means is that the sources for clang/llvm are downloaded
separately from the toolchain build (which also means we finally only
download a given version of clang once for all platforms).
In turn, this means the build-clang.py script needs to start with an
existing llvm-project tree, and we choose to make build-clang.py expect
that it's run from the llvm-project root directory.
This also means we don't need to download git for the windows toolchain
task.
Differential Revision: https://phabricator.services.mozilla.com/D40402
Bug 1546136 wrapped subprocess execution output to capture cmake's, but
at the detriment of other output, and hiding everything unless an error
occurs.
So instead, we only capture the output when the called process is cmake,
and even when it is cmake, we don't pipe stderr at all (since we only
care about cmake's stdout) and we print out stdout as it comes in rather
than later. We then later check the output for hints at the more useful
cmake logs and dump them.
While here, add verbosity to ninja output (which gives the command
lines, rather than generic "Building foo.o" output).
Differential Revision: https://phabricator.services.mozilla.com/D40142
Credit: Callek for figuring out an issue in 'make check' making the binary
absolute in mozbuild.base.
Differential Revision: https://phabricator.services.mozilla.com/D37319
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
This will match the compiler version Tor would like. We backport several
llvm-objcopy patches that landed right after the 8 branch though. We
also grab some upstream changes from mingw-clang in the build script
Differential Revision: https://phabricator.services.mozilla.com/D31347
--HG--
extra : moz-landing-system : lando
Analogously to the existing `linux64-clang-8-android-cross` build, this
build is a linux x86-64 build with runtime library support for aarch64.
Depends on D28405
Differential Revision: https://phabricator.services.mozilla.com/D28406
--HG--
extra : moz-landing-system : lando
This change enables us to build compiler-rt and related
libraries (e.g. address sanitizer, etc.) for whatever targets we like,
assuming that we have an accessible sysroot for the target on the build
machine.
Depends on D28404
Differential Revision: https://phabricator.services.mozilla.com/D28405
--HG--
extra : moz-landing-system : lando
CMake errors can be pretty opaque, especially if CMake is being run
inside the Ninja build process. Let's try to surface those errors to
make problems easier to debug.
Differential Revision: https://phabricator.services.mozilla.com/D28360
--HG--
extra : moz-landing-system : lando
It seems better to set switches enabling runtime libraries and switches
enabling runtime libraries to build in different places, as future
changes might only enable runtime libraries for certain targets, but not
need any special switches for building.
Depends on D27594
Differential Revision: https://phabricator.services.mozilla.com/D27595
--HG--
extra : moz-landing-system : lando
`android_targets` here is a dict, not a sequence, and while `iter` on a
dict object implicitly means `dict.iterkeys()`, that's not really
obvious. We should instead be explicit about what we're doing here.
Depends on D27593
Differential Revision: https://phabricator.services.mozilla.com/D27594
--HG--
extra : moz-landing-system : lando
We don't need them and we might as well be explicit about not building them.
Depends on D27592
Differential Revision: https://phabricator.services.mozilla.com/D27593
--HG--
extra : moz-landing-system : lando
The setup for compiler-rt is currently done before the stage 2 build,
which happens to be the final stage for our android runtime libraries
build. But we may also want to build runtime libraries on 3-stage
bootstrap builds, in which case we don't want compiler-rt to be active
for the second stage. Move the setup into build_one_stage so that the
setup is controllable by is_final_stage, which is set in all the place
that we care about.
Differential Revision: https://phabricator.services.mozilla.com/D27592
--HG--
extra : moz-landing-system : lando
Nathan Froyd
Andi-Bogdan Postelnicu
Chris Manchester
David Major
Brindusan Cristian
Sylvestre Ledru
Daniel Varga
Mike Hommey
Bogdan Tara
Andrew Halberstadt
Andreea Pavel
Coroiu Cristina
Tom Ritter
Gabriele Svelto
Jesse Schwartzentruber
Christian Holler