Work around address space exhaustion with 32-bit Rust
on Windows by building with the current beta, which
does not show the problem, likely because of more
efficient llvm ir generation.
See bug 1417268 for discussion.
MozReview-Commit-ID: 1MkFsi4REah
--HG--
extra : rebase_source : 039800ad3e87fdc7b9e24a64a7da4f36c5e8fd75
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : a3f0a76b1ae6b3cd952271782f9d0c2463b704e0
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : 9aecfab8a8ce41441fb4c25021b14263d9c115c2
This doesn't offer much advantage since it's the still
the primary rust builders are using for this target.
I meant to remove it before landing bug 1421100.
MozReview-Commit-ID: ATYlPWFFs8O
--HG--
extra : rebase_source : 3cf8818e29d2d25b72715e197a3d66491c6409d0
Work around address space exhaustion with 32-bit Rust
on Windows by building with the current beta, which
does not show the problem, likely because of more
efficient llvm ir generation.
See bug 1417268 for discussion.
MozReview-Commit-ID: 1MkFsi4REah
--HG--
extra : rebase_source : 653478fbde2a64d1f08fe6708fa4126e38452060
New stable release.
We leave the win32 builds on rust 1.21.0 for now:
- Building with 1.22.1 fails on win32 opt, we think, because
the code tree passed to llvm exhausts 32-bit address space
under -Clto. Bug 1417268.
- Resolving the above by building with 64-bit rust is blocked
by build.rs scripts not picking up the correct platform in
automation builds. Bug 1401647.
- Building with 1.23.0-beta.1 fails on win32 debug with a
bindgen panic. Bug 1420301.
MozReview-Commit-ID: 9Q1K7dSBlEv
--HG--
extra : rebase_source : 84d1d0306934fffceda7b242615d89722d02c6f5
Per schedule, bump the minimum-supported rust version to 1.21.0
two weeks after its stable release so we can use new code which
depends on it.
MozReview-Commit-ID: Bn8UjvTC7uw
Except ASAN builds, which for some reason fail with that version
(bug 1409267).
--HG--
extra : rebase_source : e91bd0f4cd152be57abd5cddb8e15e4af34912bb
New upstream release.
Maintain a linux64-rust-1.20 for use verifying the minimum-
supported rust version once we update it.
We still use rust 1.19 to build sccache since there are
network connection issues when it's built with more recent
rust releases.
MozReview-Commit-ID: 9KjdYAAQZRa
--HG--
extra : rebase_source : 48a9512351723c7cc9a3ac1414097811f2d93720
The only tricky piece here is that the resulting toolchain archive is
private, and uses a newly allocated Task Cluster scope
(queue:get-artifact:project/gecko/android-sdk/*) to restrict access to
the archive. All SCM levels (1, 2, 3) have been given the new scope:
see https://tools.taskcluster.net/auth/roles/moz-tree:level:1 and
friends.
MozReview-Commit-ID: CcDqDOHODpe
--HG--
extra : rebase_source : 81dbb065f2a3c4e7733e964be66adb1733db52c6
When adding sccache toolchain jobs in bug 1381772, building with gcc
failed, and building with clang worked, so I just went with the path of
least resistance. That's however a suboptimal position in the dependency
graph, so it's still preferable to use gcc if possible.
Looking exactly how it fails, it turns out it's because without CC being
set, ring wants to build with "cc", which ends up being the system gcc
instead of ours (our gcc archive doesn't provide "cc", only "gcc"), and
it is too old to support the compiler flags ring uses.
So setting CC does the trick.
--HG--
extra : rebase_source : 4c657664957dff1f7aebe470e0440a52c9e280e5
The only tricky piece here is that the resulting toolchain archive is
private, and uses a newly allocated Task Cluster scope
(queue:get-artifact:project/gecko/android-sdk/*) to restrict access to
the archive. All SCM levels (1, 2, 3) have been given the new scope:
see https://tools.taskcluster.net/auth/roles/moz-tree:level:1 and
friends.
MozReview-Commit-ID: CcDqDOHODpe
--HG--
extra : rebase_source : 062bca8c65556f0f46e9c9cc6cd81eb04cf2b522
New upstream stable release.
Maintain rust-1.19 builds for verifying the minimum-supported
version, and because we have network failures when we build
sccache with rust 1.20 or 1.21.
MozReview-Commit-ID: 5qi8JDTjfzj
Add a toolchain job description which calls the
repack_rust.py script to package the requested
upstream build of Rust and its standard libraries
for use in gecko builds.
Links are added to these new toolchains for various build
and analysis tasks as appropriate. The base-toolchain
tasks use an explicitly-versioned toolchain since those
can be different from the current release used for most builds.
The corresponding tooltool manifest entries are removed
now that taskcluster artifact versions are available.
This simplifies the update process since new toolchains
can be packaged and used automatically by just updating
the versions in the task descriptions.
A 'linux64-rust' toolchain can be added to other tasks
as a dependency and artifact. It supports linux64-
hosted builds of Rust code targeting linux64 or linux32.
A 'linux64-rust-macos' toolchain targets linux64-hosted
builds of Rust code targeting macOS on x86_64.
A 'linux64-rust-android' toolchain targets linux64-hosted
builds of Rust code targeting various Android architectures.
Two 'win64-rust' and 'win32-rust' toolchain tasks create
similar entries for Windows-hosted builds. All our automation
builds are hosted on win64, so we could use one artifact
with support for both targets, but currently this doesn't
work because of cross-compilation issues in some crates.
This patch maintains the previous separation between
win32 and win64 rust toolchains until that can be addressed.
MozReview-Commit-ID: GRiJml8CtzO
--HG--
extra : rebase_source : 09a3698ce7f9a8b5f2b5d9b5a1fde9c05dc6b540
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
While this looks like going backwards, it is desirable to build clang
against GCC 4.8, such that it contains its libgcc. This, in turn, will
solve problems using clang 3.9 with static-analysis builds (details in
bug 1356926). Another way to fix those problems would be to build clang
3.8 but that too would require GCC 4.8. Upgrading those builds to clang
3.9 will also allow to enable stylo on them.
It becomes a library of some sort, so that multiple scripts can benefit
from it to build different versions of GCC.
The GPG key associated with GCC is also refreshed from keys.gnupg.net,
adding a new subkey, used to sign newer versions of GCC (and
postprocessed with pgpstrip to make it smaller).
We're soon going to build multiple versions of clang and gcc for linux,
and we need to differentiate them. Furthermore, there is a need for the
base-toolchains builds to use a fixed version of clang and gcc. So
rename the clang and gcc toolchain jobs to include their version, add
aliases to satisfy all existing jobs, and adjust the base-toolchains
jobs to use the explicit version.
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-3.9-linux64.json
rename : taskcluster/scripts/misc/build-gcc-linux.sh => taskcluster/scripts/misc/build-gcc-4.9-linux.sh
