The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
- Update the tooltool manifests to use the new package.
- Update mozconfig paths to reflect MSVC tooltool package changes.
--HG--
extra : rebase_source : 2f2da35ec1d1b3fb5ca9210951d9ac3a38a2bd75
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
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
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
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.
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 : source : 56b27306d3257445f70374aa78fc5bd42ef300ce
extra : intermediate-source : 559a80645f20706e1eaaeed863e90c2d35ff7644
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
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/*
Nathan Froyd
Mike Hommey
Wes Kocher
Carsten "Tomcat" Book
Ralph Giles
Steve Fink
Kim Moir
Sebastian Hengst
Gregory Szorc
Ehsan Akhgari
Justin Wood
Nick Thomas