That is what rust uses, and versions of rust >= 1.44 make the
discrepancy visible as a linker error on missing the _Unwind_Resume
symbol, so we need to align things.
Differential Revision: https://phabricator.services.mozilla.com/D93725
This patch fixes various issues that prevented us from running chromium/chrom in raptor-browsertime.
(1) Chromium fetch task now also fetches the latest chromedriver.
(2) FFMPEG failures when recording on chrome/chromium.
(3) Various changes where chromium wasn't considered as a variant of chrome.
Differential Revision: https://phabricator.services.mozilla.com/D92646
All the workers that had hg under /tools/python27-mercurial are gone.
This also fixes run-task for workers running > 10.14.
Differential Revision: https://phabricator.services.mozilla.com/D92867
All the workers that had hg under /tools/python27-mercurial are gone.
This also fixes run-task for workers running > 10.14.
Differential Revision: https://phabricator.services.mozilla.com/D92867
This extracts an install-meson.sh helper script to install meson in both
the wrench-deps task for Firefox CI and the taskcluster.yml in WebRender CI.
Differential Revision: https://phabricator.services.mozilla.com/D90441
Without setting this variable, the call to `mach python` in `taskcluster/scripts/builder/build-linux.sh` will create a `virtualenv` in the default location -- on Linux in CI, that's `obj-x86_64-pc-linux-gnu`. Everything else about the build is going to end up in `obj-build`, so just set `MOZ_OBJDIR` appropriately to point to that directory.
Doing so enables us to land bug 1663755, as it causes the logic added to `symbols_archive.py` as part of bug 1654994 to behave as expected.
Differential Revision: https://phabricator.services.mozilla.com/D89975
The script uses the `cd $FOO && pwd` trick to fix the path style on Windows, but currently this happens before the `mkdir`, so we get an incorrect result:
```
[task 2020-09-11T03:38:59.656Z] ++ cd Z:/task_1599794667/public/build
[task 2020-09-11T03:38:59.656Z] ./src/taskcluster/scripts/builder/build-sm.sh: line 10: cd: Z:/task_1599794667/public/build: No such file or directory
[task 2020-09-11T03:38:59.656Z] ++ pwd
[task 2020-09-11T03:38:59.657Z] + export MOZ_UPLOAD_DIR=/z/task_1599794667
```
Differential Revision: https://phabricator.services.mozilla.com/D89925
This improves the integrity of downloads of upstream artifacts when using fetch-content. If `verify-hash: True` is set on the fetch config, then the chain-of-trust.json of the upstream is used to retieve the expected sha256 of the artifact, and this is checked.
Differential Revision: https://phabricator.services.mozilla.com/D87725
This improves the integrity of downloads of upstream artifacts when using fetch-content. If `verify-hash: True` is set on the fetch config, then the chain-of-trust.json of the upstream is used to retieve the expected sha256 of the artifact, and this is checked.
Differential Revision: https://phabricator.services.mozilla.com/D87725
Also reflects the move from CraneStation to the WebAssembly account. And we need a small tweak to the build script to accommodate one of the changes that got picked up along the way.
Differential Revision: https://phabricator.services.mozilla.com/D88187
In Bug 1466660, we started deleting the fetches after a task had run, to avoid
interference between tasks. It turns out the only tasks this was for were the
`source-test-jsshell` tasks, which were changed to use an absolute directory in
Bug 1465181. However, since Bug 1568460 we've always used a per-task directory
for fetches, so can remove the work-around of removing fethes.
Differential Revision: https://phabricator.services.mozilla.com/D86670
In Bug 1466660, we started deleting the fetches after a task had run, to avoid
interference between tasks. It turns out the only tasks this was for were the
`source-test-jsshell` tasks, which were changed to use an absolute directory in
Bug 1465181. However, since Bug 1568460 we've always used a per-task directory
for fetches, so can remove the work-around of removing fethes.
Differential Revision: https://phabricator.services.mozilla.com/D86670
In Bug 1466660, we started deleting the fetches after a task had run, to avoid
interference between tasks. It turns out the only tasks this was for were the
`source-test-jsshell` tasks, which were changed to use an absolute directory in
Bug 1465181. However, since Bug 1568460 we've always used a per-task directory
for fetches, so can remove the work-around of removing fethes.
Differential Revision: https://phabricator.services.mozilla.com/D86670
This adds a new job variant `arm64-cranelift-sim` to the SpiderMonkey
build configurations, and adds a Taskherder CI configuration to run it.
The job uses the aarch64 simulator support built-in to SpiderMonkey, so
it does not need to run on native aarch64 hardware.
A few tests needed to be added to the "slow tests" list as they time out
under the simulator otherwise.
This also fixes an issue with an error message in `build-sm.sh` in which
the overloading of the backtick's meaning (code-quotes in
Markdown-world, and command interpolation in shell scripts) led to an
amusing attempt to execute parts of the error message.
Finally, this fixes an error that seems unrelated to Cranelift or
WebAssembly in a GC jit-test, wherein its way of measuring maximum stack
recursion depth was failing.
Differential Revision: https://phabricator.services.mozilla.com/D86131
I've left the monitor disabled for now, so that we can have a smaller pushes for enabling and disabling it if needed. It should allow more fine grained control.
We may also want to include extracting the monitor tool from a github version instead, and also removing the assumption and it being forked from the parent, so that it's instead given a process ID to treat as the parent it should watch.
Differential Revision: https://phabricator.services.mozilla.com/D84374
This adds a makecab toolchain for Linux. It's not hooked anywhere
because bug 1654994 will also move the use of makecab to upload-symbols
tasks, so hooking the toolchain up with builds would be a waste of
time.
Differential Revision: https://phabricator.services.mozilla.com/D84789
I suspect these were an artifact of building the checked-out repository
inside the Firefox source directory, but that is not a problem anymore.
Differential Revision: https://phabricator.services.mozilla.com/D84363
We don't need this for our (current) builds, which are cross-builds, but we
would need this at some future date if we ditched the breakpad `dump_syms`.
Depends on D83528
Differential Revision: https://phabricator.services.mozilla.com/D83529
I suspect these were an artifact of building the checked-out repository
inside the Firefox source directory, but that is not a problem anymore.
Differential Revision: https://phabricator.services.mozilla.com/D83528
Changes:
- create a `test-android.sh` script that is based on, but removes non-android related paths from the `test-linux.sh` script.
Differential Revision: https://phabricator.services.mozilla.com/D82252
Changes:
- create a `test-android.sh` script that is based on, but removes non-android related paths from the `test-linux.sh` script.
Differential Revision: https://phabricator.services.mozilla.com/D82252
These scripts don't call `build-clang.py`, they just repackage artifacts from other tasks that do.
I went with `repack` over `repackage` since that seems to be the established pattern in `taskcluster/scripts/misc/`.
Differential Revision: https://phabricator.services.mozilla.com/D83532
Currently the macosx-cross toolchain build pulls in a linux64-clang toolchain, uses it to build a Mac native toolchain, and then clobbers the result with pieces of the Linux toolchain. This means that the same version of LLVM is used to build the Mac pieces and be part of the final artifact. This will become a problem with upcoming LLVM 11 where we'll want to build the Mac pieces with LLVM 9 but otherwise repackage an LLVM 11 Linux toolchain.
So this commit makes the macosx-cross workflow look more like the win-cross one: take two compilers built elsewhere and just merge them.
Differential Revision: https://phabricator.services.mozilla.com/D83378
LLVM 11 introduces a hard requirement for SDK 10.12 in order to build for Mac. We want to keep building older LLVMs with 10.11 though, so this patch adds some flexibility so that build-clang can make use of whatever SDK package a particular task pulls from tooltool (but still requesting a deployment target of 10.11).
Differential Revision: https://phabricator.services.mozilla.com/D82621