There are now only two left:
- one for the OSX 10.11 SDK
- one for Visual Studio 2017
Differential Revision: https://phabricator.services.mozilla.com/D40751
MANUAL PUSH: avoid closing autoland while all docker images and
toolchains are rebuilt.
--HG--
rename : browser/config/tooltool-manifests/win32/build-clang-cl.manifest => browser/config/tooltool-manifests/win64/vs2017.manifest
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
It turns out version 15.4.2 spawns a vctip process that sticks after the
build, and since bug 1527798, that breaks unmounting caches because the
process has a handle on msvcp140.dll, which lies in the source
directory. The problem goes away with 15.8.4, so upgrade all toolchain
tasks to that.
That's the same version as we're using on x86/x86-64 MSVC builds.
Differential Revision: https://phabricator.services.mozilla.com/D19752
to give time to docker images and toolchains to build.
--HG--
rename : taskcluster/docker/debian-raw/cloud-mirror-workaround.sh => taskcluster/docker/debian-base/cloud-mirror-workaround.sh
rename : taskcluster/docker/debian-raw/setup_packages.sh => taskcluster/docker/debian-base/setup_packages.sh
It turns out version 15.4.2 spawns a vctip process that sticks after the
build, and since bug 1527798, that breaks unmounting caches because the
process has a handle on msvcp140.dll, which lies in the source
directory. The problem goes away with 15.8.4, so upgrade all toolchain
tasks to that.
That's the same version as we're using on x86/x86-64 MSVC builds.
Differential Revision: https://phabricator.services.mozilla.com/D19752
It turns out version 15.4.2 spawns a vctip process that sticks after the
build, and since bug 1527798, that breaks unmounting caches because the
process has a handle on msvcp140.dll, which lies in the source
directory. The problem goes away with 15.8.4, so upgrade all toolchain
tasks to that.
That's the same version as we're using on x86/x86-64 MSVC builds.
Differential Revision: https://phabricator.services.mozilla.com/D19752
The minidump_stackwalk used for tests ifs picked up from tooltool, and
it looks like the tooltool manifests haven't been updated in 2 years.
As it turns out, this old version is not capable of, at least, stack
walk over crashes originated in LTOed rust code on Windows, while
breakpad trunk, as well as the slightly oldest version we have in-tree
do.
While ideally, we'd go with building minidump_stackwalk as a taskcluster
toolchain artifact, or during the build, but that involves significantly
more work, while we should fix the stack traces of crashes that people
_do_ get as early as possible.
The tooltool artifacts linked in the updated manifests were generated
the following way:
- Revert the last two changes that happened to minidump_stackwalk.cc
between 2016 and now (they don't matter for functionality and get in
the way of the rest below).
- Apply the changes betwen the version of minidump_stackwalk.cc from
2016 and
https://hg.mozilla.org/users/tmielczarek_mozilla.com/stackwalk-http/raw-file/51e4725ffad4/stackwalk.cc
- Pick the http_symbol_supplier.cc and http_symbol_supplier.h files from
the same repo as stackwalk.cc above.
- Add the necessary build system bits to build it off the Gecko tree,
along with the in-tree breakpad code.
- Build it for linux, linux64, macosx64, win32-mingw.
The patch doing all the above is:
https://hg.mozilla.org/try/rev/64491336dc7fca7a1c00ae8c66619b01563bbe4e
The push to build it on the aforementioned platforms:
https://hg.mozilla.org/try/rev/4b621a67ca0bd6cf8954566e180d23e1ba8a9f83
A win64-mingw variant was also built, but is not being used, keeping
things in line with what we currently are using. We may want to follow
up with an update to use that win64 variant on 64-bits testers.
Differential Revision: https://phabricator.services.mozilla.com/D14005
--HG--
extra : moz-landing-system : lando
If you happen to be unfortunate enough to be testing changes that crash
xpcshell during the xpcshell self-tests, you'll be presented with error
messages like:
PROCESS-CRASH | test_child_assertions.js | application crashed [unknown top frame]
Crash dump filename: c:\users\task_1522676338\appdata\local\temp\xpc-other-mtot6h\cfaea928-e995-4430-baf9-0066c6b91be9.dmp
MINIDUMP_STACKWALK binary not found: z:\build\build\tools\breakpad\win64\minidump_stackwalk.exe
and then be told that, essentially, "your test failed because it
failed", which is unhelpful for figuring out what went wrong.
Apparently we had MINIDUMP_STACKWALK set at one point, and then it got
moved. Let's fix this situation by a) downloading minidump_stackwalk
out of tooltool (our test harnesses do this already); and b) pointing
MINIDUMP_STACKWALK at the correct location. With these changes, we can
once again get crash stacks if xpcshell (and probably a few other
things) fail their self tests.
OSX (cross) repackages are currently using a tooltool manifest to get
libdmg and hfsplus. Change those jobs to use the toolchain artifacts
instead.
At the same time, modify the repackage mozharness script's _run_tooltool
so that it doesn't fail with MOZ_TOOLCHAINS being set but without a
tooltool_manifest_src, matching the similar function in buildbase.py.
--HG--
extra : rebase_source : d128d4709c5d1d28d1a6b9c585fde82e99f725c7
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : d8447b5422e63e88444008fddb76d658829694de
It turns out that in all cases it was the last tooltool manifest entry,
so we can remove the tooltool manifests entirely, and remove all
references to them.
--HG--
extra : rebase_source : 0aa9ef8151c2fccf62507dfecc0bc57b157772e1
The new VS package is now based on update 15.4.2, although that release didn't affect any files in our package. I'm picking up the update mostly just to make filename unique.
Repack of the new Visual Studio release using the packaging
scripts from bug 1407678. This version also includes the
pgo runtime, resolving a performance regression from the
previous package.
MozReview-Commit-ID: LhoVyG4IwmP
--HG--
extra : rebase_source : 0d3d2f28f05335976d236e5f76893307c252dc96
Repack of Visual Studio 2017 15.4.0 with SDK 10.0.16299.0
created by David Major by running the installer on a fresh
VM and then running the updated packaging script from
bug 1407678.
MozReview-Commit-ID: 7ZKoA6ncOPr
--HG--
extra : rebase_source : dcb72a71f34ada6ead631fe8fac0b31f0ddb8e29
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
Mike Hommey
Sebastian Hengst
Sylvestre Ledru
Bogdan Tara
Nathan Froyd
Ryan VanderMeulen
Kartikaya Gupta
Masatoshi Kimura
Margareta Eliza Balazs
Coroiu Cristina
Steve Fink
Andreea Pavel
David Major
Ralph Giles
Ted Mielczarek