Repacks of upstream builds cargo 0.13.0-nightly (664125b 2016-07-19)
for each host platform. Unpacks into cargo/bin/cargo.
This version supports `cargo build --frozen` to disallow
network access during the build.
MozReview-Commit-ID: IihpDlqxPx6
Repacks of upstream rust 1.10.0 stable builds with cargo and std for necessary target architectures.
MozReview-Commit-ID: CgPukGLz4Dv
--HG--
extra : rebase_source : e393c1f0aa4e8d14861ed5bb76f1ac73bfcab444
Gecko builds of rustc and cargo. x86_64-unknown-linux-gnu host
targeting both x86_64 and i686.
rustc built with --enable-llvm-static-stdcpp --disable-docs
--enable-debuginfo --release-channel=stable from 'stable' branch
rust 1.10.0 (commit cfcb716cf0961a7e3a4eceac828d94805cf8140b)
cargo built from 'master' branch
cargo 0.11.0-119-g9f1ffdd (commit 9f1ffdd69b9fc564431e027a5043b303c7ec3808)
MozReview-Commit-ID: 4hq6dan8pk0
Needed because buildbot clones/checks out from the repo head (of default)
and then updates to the rev for the nightly we're pulling, which can cause
CLOBBER file changes to initiate an unwanted clobber of the object directory
where we just pulled the nightly binary from. Even when CLOBBER hasn't actually
been touched in the changeset range we're looking at between nightlies.
MozReview-Commit-ID: 154d2iZeHgd
--HG--
extra : rebase_source : 504b821955a870cabf6fc727d13e44a33aabb45c
Something similar was done in bug 1278718 for ASan builds, because of
indirect dependencies on libstdc++ being picked by the linker and
leading to linkage failure with the older binutils from the CentOS 6
image we use to do desktop builds.
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Custom build of rust 1.9.0 stable for gecko with
--enable-llvm-static-stdcpp --disable-docs --release-channel=stable
--enable-debuginfo for x86_64-unknown-linux-gnu targeting
x86_64-unknown-linux-gnu and i686-unknown-linux-gnu.
MozReview-Commit-ID: 1ycJzrPGkeA
We were using 1.9 beta for i586 support. Now that it's no longer
necessary we can revert to the stable release.
This is a repack of the 1.8.0 upstream stable build targetting
only i686-pc-windows-msvc.
MozReview-Commit-ID: 7ieQ9steK5k
We were using 1.9 beta for i586 support. Now that it's no longer
necessary we can revert to the stable release.
This is a repack of the 1.8.0 upstream stable build targetting
only i686-pc-windows-msvc.
MozReview-Commit-ID: 7ieQ9steK5k
Pass --enable-rust for official Firefox builds on 32-bit
linux. This enables it for all channels, just like other
platforms.
MozReview-Commit-ID: BCQrOVkGNtJ
This is the same repack of the upstream 1.8.0 stable build
for x86_64-unknown-linux-gnu hosts plus the i686 and
x86_64 std libraries used for the linux64 builds.
MozReview-Commit-ID: Gfd9YkNVe4K
compare-mozconfigs-wrapper.py complains that mozconfig.rust
is included in mozconfigs\win64\release but not
mozconfigs\win64\release even though it is.
We've let this ride the trains for other archs. Should do so
for win64 as well.
MozReview-Commit-ID: D7dS9femsBj
--HG--
extra : rebase_source : 1bb5919009e005f29420fdff6cc472ae104b8421
Rust 1.8 added unwind support. but 1.9 is the first release
with i586 target support without SSE2 instructions in the
standard library, which we need for compatibility with older
machines, so we need to stay on 1.9 until it's in stable release.
This is a repack of the upstream 1.9.0-beta.1 compiler build
for i686-pc-windows-msvc hosts and both i686 and i586 targets.
MozReview-Commit-ID: Ed6ND7NE1F1
--HG--
extra : rebase_source : 82587d7c2f1798f1ceb5dab708740e2bdfb62af3
This is a repack of the upstream 1.8.0 stable compiler build
for x86_64-pc-windows-msvc hosts and the corresponding std
library.
MozReview-Commit-ID: 6vHDTQgeKBW
--HG--
extra : rebase_source : 90f7daf3defdcd0967dae4a8a2827a143e7b2b65
This is a repack of the upstream 1.8.0 stable build
for x86_64-unknown-linux-gnu hosts plus the i686 and
x86_64 std libraries.
MozReview-Commit-ID: F6q9Y51ow8U
--HG--
extra : rebase_source : 50538ed05bf744f6513f57d2847f751dcc8c40e1
Ideally, we'd use the tarballs from
http://llvm.org/releases/download.html but I didn't feel like modifying
the script more than I already did to make it work at all (bug 1262735).
The new tarball for Linux was built on
https://tools.taskcluster.net/task-inspector/#LCUn8aEgTBeRJ11a3qTlDQ/0
The new tarball for Mac was built on a loaner, after installing cmake
and ninja, as well as building ld64 127.2 from source because the
installed version would assert while building clang. The latter required
manually adding some missing headers to /usr/include. TSAN was also
disabled because it requires APIs that are not available on the OSX
version on the build slaves (e.g. pthread_introspection_hook_install).
Building clang also required using a mac clang from tooltool, the system
one lacking support for atomics.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
