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".
Update win32 builds to use a Repack of today's (2016 April 1)
rustc nightly for i686-pc-windows-msvc host and
i586-pc-windows-msvc target.
This should properly support machines without sse2 instructions.
This commit switches Windows builds from Visual Studio 2013
to Visual Studio 2015 Update 1.
Previously, Visual Studio was installed on the builders as part
of the base system image. Starting with this commit, we obtain
Visual Studio from a pre-generated, self-contained archive
containing the executables, Windows SDK, and other support
files. This means that new Windows toolchains can be installed
without having to modify configuration of machines in automation!
The mozconfigs for Visual Studio 2015 are a bit different from
existing mozconfigs.
Because it appears to be completely redundant and not necessary,
the LIBPATH variable has been dropped.
The order of paths in PATH, LIB, and INCLUDE has changed. The new
order more accurately reflects what would be defined by
vcvarsall.bat.
As part of switching to Visual Studio 2015, the Universal CRT is
now required. So, the 2015 mozconfigs export WIN_UCRT_REDIST_DIR
to define the location to those files.
The switch to Visual Studio 2015 also involves the switch from
the Windows 8.1 SDK to the Windows 10 SDK. However, we still
target an old version of Windows, so this hopefully shouldn't
have any significant fallout.
It's worth noting that switching to Visual Studio 2015 makes
builds - especially PGO builds - significantly faster. Our
PGO build times in automation are ~1 hour faster. Our regular
builds appear to be a few minutes faster.
MozReview-Commit-ID: Pa5GW8V87Q
--HG--
extra : rebase_source : bff4fad17f781d8d21bdb941bdd500955d1e9f08
extra : amend_source : faa3038c290fdf5cdd3e24a45ba2a37490f68c17
extra : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
We're still using a i686-pc-windows-msvc rust stdlib,
but now that bug 1255869 we have runtime protection against
calling the sse2 code it contains.
Reverts bug 1253456.
--HG--
extra : rebase_source : 28c7399eb9f90f2865c41eb394a5949e05a632ff
Build from source of rust 1.7.0 stable configured with
--enable-llvm-static-stdcpp --disable-docs --release-channel=stable
and --target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu
using the quay.io/rust/rust-build-gecko docker image.
https://github.com/rillian/rust-build commit e4902d5a072b.
https://tools.taskcluster.net/task-inspector/#ZSNL6FCoT7mWahGGxpWCOQ/0
--HG--
extra : rebase_source : 134c3a5d10c12b7e0b62b617f193b024d0b5e417
Repacked official beta builds of rustc 1.8 and the std library.
We still need the unwind fixes in 1.8, but want to update
now that version is in beta. This doesn't address the sse2
issues with the std library code; see bug 1253202.
--HG--
extra : rebase_source : 8cf31b8946418199aa74499fcdfa40b7ef2b2161
Until we can address the sse2 code generation issue,
disable rust on win32 nightly, beta, and release builds.
Leave it enabled in debug builds for testing convenience.
This uses a repacked version of the upstream 1.8 nightly
builds. We need 1.8 for WinXP support, but it's safe to
use nightly until this stablises because other platforms
are using stable rust and will catch any nightly-only
feature use.
For these builds I used the channel-rustc-nightly manifest instead
of the older channel-rust-* manifest, to get the separate std packages.
tar xf rustc-nightly-i686-pc-windows-msvc.tar.gz
rustc-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar xf rust-std-nightly-i686-pc-windows-msvc.tar.gz
rust-std-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar cjf rustc.tar.bz2 rustc/*
We're already riding the trains on macosx and linux64, enabling
this for all channels this avoids having to whitelist the config.
This uses a repacked version of the upstream 1.8 nightly
builds. We need 1.8 for WinXP support, but it's safe to
use nightly until this stablises because other platforms
are using stable rust and will catch any nightly-only
feature use.
For these builds I used the channel-rustc-nightly manifest instead
of the older channel-rust-* manifest, to get the separate std packages.
tar xf rustc-nightly-i686-pc-windows-msvc.tar.gz
rustc-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar xf rust-std-nightly-i686-pc-windows-msvc.tar.gz
rust-std-nightly-i686-pc-windows-msvc/install.sh --prefix=rustc/
tar cjf rustc.tar.bz2 rustc/*
Now that we have cross-compilation tooltool packages for OS X, we can
use the common mozconfig to enable Rust on all OS X builds, regardless
of host OS.
The unix mozconfig.rust is actually completely generic now that we're
using toolchains built with --enable-rpath in tooltool.
Move the mozconfig.rust fragment up a level to reduce confusion.
Custom build of the stable git branch (tag 1.6.0) with
MACOSX_DEPLOYENT_TARGET=10.7 and configured with
--enable-rpath --disable-elf-tls --disable-docs
and --target=x86_64-apple-darwin,i686-apple-darwin for cross-32
support. Built using the build_rust_mac.sh script from
https://github.com/rillian/rust-build.
Build from source of rust 1.6.0 stable configured with
--enable-rpath --enable-llvm-static-stdcpp and
--target=x86_64-unknown-linux-gnu,i686-unknown-linux-gnu
so it supports -m32 builds, using the docker image at
https://github.com/rillian/rust-build on taskcluster.
Custom build of stable rustc 1.5 with --enable-rpath
--enable-llvm-static-stdcpp and --target=i686-unknown-linux-gnu.
https://github.com/rillian/rust-build commit fe6d07b8b86c.
Custom build from 1.5.0-src with MACOSX_DEPLOYMENT_TARGET=10.7
--enable-rpath --disable-elf-tls --disable-doc with i686 rustlib
copied into the x86_64 install for cross-32 support.
Custom build of stable rustc 1.5 with --enable-rpath
--enable-llvm-static-stdcpp and --target=i686-unknown-linux-gnu.
https://github.com/rillian/rust-build commit fe6d07b8b86c.
Custom build from 1.5.0-src with MACOSX_DEPLOYMENT_TARGET=10.7
--enable-rpath --disable-elf-tls --disable-doc with i686 rustlib
copied into the x86_64 install for cross-32 support.
Update tooltool manifest for macosx with a custom build of rustc 1.4.0
with --enable-rpath --disable-elf-tls and MACOSX_DEPLOYMENT_TARGET=10.7
on MacOS X 10.10.5, Xcode 7.1.1 (clang-700.1.76).
Built for x86_64-apple-darwin with the rustlib from a separate
i686-apple-darwin build copied into the tree to support 32-bit cross
for universal builds.
Since we've enabled rpath, we can drop the DYLD_LIBRARY_PATH setting
from mozconfig.rust. This method seems cleaner since the add/append
decision for DYLD_LIBRARY_PATH is verbose in shell.
