Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
Doing so changes the size of the compressed toolchain archive from ~280M
to ~120M, and the decompressed size from ~1500M to ~675M. This will
reduce the overhead of decompression during builds.
As we ship llvm-symbolizer as part of ASan builds, we do need it to
still statically link against LLVM, which we do with a small patch.
With LLVM as a shared library, libLTO, which is used by cctools-port for
the linker, is dynamically linked to LLVM, and the cctools-port
configure script fails to link against libLTO. So we add a -rpath-link
to make it find the LLVM library. This happens to force a rebuild of
cctools-port, but for future cases where we might need a rebuild because
of some clang changes, we add a comment to ease the process, and avoid
a newer cctools-port taking the cache spot of an older one.
Ideally, mac cctools-port would need something similar, but it needs a
mac libLTO.dylib, which is not there anyways (and the mac cctools-port
thus already didn't support LTO).
Also, with LLVM built as a shared library, all its symbols are exported
with a LLVM_x.y version. Combined with -static-libstdc++ that is used
during the clang build, this causes problems (see
https://bugzilla.mozilla.org/show_bug.cgi?id=1492037#c7). But it turns
out things have evolved since -static-libstdc++ has been added to the
clang build script, and things work without now, so remove it (as well
as -static-libgcc).
Differential Revision: https://phabricator.services.mozilla.com/D6117
This updates the rust-size build to reference the latest version [1] that
includes a work-around for calculating the .bss of a PE file that has a
writable section with a smaller on-disk size than in-memory size.
[1] ab659d93b1
--HG--
extra : rebase_source : 24b451d244cd0533ca550688ccc05976cae410c7
Last time it was updated is bug 1436208, and the crashes we patched it
for back then has been fixed upstream a few months later.
For some reason, they renamed the executable from llvm-dsymutil to
dsymutil.
Differential Revision: https://phabricator.services.mozilla.com/D4741
--HG--
extra : moz-landing-system : lando
Rather than trying to parse strings, just pass a json blob. This will allow us
to easily do things like mark artifacts to be left unextracted.
Differential Revision: https://phabricator.services.mozilla.com/D3553
--HG--
extra : rebase_source : 4e762c65d1c9f13361d5bae2e4608ba09bb39a91
This also moves the call to 'fetch_artifacts' in run-task down inside the
try/finally block. This way if something goes wrong, we'll still cleanup
MOZ_FETCHES_DIR.
Differential Revision: https://phabricator.services.mozilla.com/D4152
--HG--
extra : moz-landing-system : lando
When different translation units contain the same symbol name, all
static, but one of them non-static, ld64 wrongfully link the references
to the static data with the non-static data, or vice versa. With libaom
and libvpx sharing data structures with the same name but different
contents, that leads to interesting failures/crashes at runtime.
This was apparently fixed in Apple ld64 from Xcode 9, but the last open
sourced version is the one from Xcode 8, so I ended up digging in the
ld64 source code and fixed the issue.
This work was merged to cctools-port upstream in
https://github.com/tpoechtrager/cctools-port/pull/59.
For the same reason as invoked in bug 1478917, though, updating to
cctools-port master is more involved than just changing a commit sha1
(as it requires building apple-libtapi, which in turn builds parts of
LLVM, which should probably be avoided), so just cherry-pick the fix.
When different translation units contain the same symbol name, all
static, but one of them non-static, ld64 wrongfully link the references
to the static data with the non-static data, or vice versa. With libaom
and libvpx sharing data structures with the same name but different
contents, that leads to interesting failures/crashes at runtime.
This was apparently fixed in Apple ld64 from Xcode 9, but the last open
sourced version is the one from Xcode 8, so I ended up digging in the
ld64 source code and fixed the issue.
This work was merged to cctools-port upstream in
https://github.com/tpoechtrager/cctools-port/pull/59.
For the same reason as invoked in bug 1478917, though, updating to
cctools-port master is more involved than just changing a commit sha1
(as it requires building apple-libtapi, which in turn builds parts of
LLVM, which should probably be avoided), so just cherry-pick the fix.
This includes a fix for the style build script hang where pthreads fork
subprocesses, as well as a fix for ignoring the icecream file lock.
MozReview-Commit-ID: 29eNcbNtwB1
Differential Revision: https://phabricator.services.mozilla.com/D4139
--HG--
extra : moz-landing-system : lando
In order to support operator==() for tagged enum, we have to bump the version to
0.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D3932
--HG--
extra : moz-landing-system : lando
This includes a patch to enable ccache support.
MozReview-Commit-ID: 9FzMQ2XX4ca
Differential Revision: https://phabricator.services.mozilla.com/D3363
--HG--
extra : moz-landing-system : lando
And require it for taskcluster build already, because it doesn't harm and lets
me put all the yml changes in the same commit.
I gave up cross-compiling for OSX after a few tries and after realizing it
wasn't enough with cctools and such, but that I also needed the Mac SDK, for
which I don't have permission...
Differential Revision: https://phabricator.services.mozilla.com/D2664
--HG--
extra : moz-landing-system : lando
Otherwise it can't be used as a context manager since it
doesn't have __enter__ or __exit__.
Differential Revision: https://phabricator.services.mozilla.com/D2672
--HG--
extra : moz-landing-system : lando
This is what a lot of programs do.
We do logging in a helper function so we can flush after every write.
Differential Revision: https://phabricator.services.mozilla.com/D2526
--HG--
extra : rebase_source : 98563aee129c16662a783122241623b8ed2fe457
Previously, we told `tar` or `unzip` to operate on an explicit file.
This worked when `tar` understood the compression format of the file.
And this worked in the majority of cases.
But `tar` does not support zstandard compression (at least not outside
extremely new versions, which aren't yet widely deployed). And not all
versions of `tar` support the `-a` argument.
This commit changes our invocation of `tar` so input data is piped
to it from Python. In the case of `tar`, we perform decompression in
Python, if possible. This allows us to support zstandard and `tar`
binaries that don't support `-a` to auto-detect the compression format.
I wanted to be consistent and always pipe the raw data via stdin.
But `unzip` doesn't appear to like this. Oh well.
We also refactor the logic around detecting archives. We have a
function to identify the archive type based on a filename. We then
pass the archive type to the extraction function and key off that
logic within. We also conditionally call extract_archive() and
fail hard in extract_archive() when things fail. This will make
future archive code easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D1576
--HG--
extra : rebase_source : 1c66396cced1b2a94a959386eecc3f512b033308
While fiddling with clang (upgrading it and applying some miscompilation
patches), my mac LTO builds started to fail because ld64 would crash
during configure.
It turns out, it was crashing trying to print a warning it shouldn't
even print out, about failure to create a cache path.
This, in turn, is due to a pointer not being initialized in the ld64
code. I sent this upstream, and this was promptly fixed:
https://github.com/tpoechtrager/cctools-port/pull/57
However, since our last update of cctools-port, upstream landed a change
that broke support for tbd files if you don't compile against the new
libtapi library. Doing so is more work than I'm ready to put here,
so we just cherry-pick the fix.
--HG--
extra : rebase_source : 131952a5233bc379943c8eb124d377525f54202f
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
Currently 'fetch' artifacts are all extracted in the same directory, this could
make the extdir messy, or in the worst case, cause file name collisions.
Some artifacts are ok to extract into the same directory as they're already
bundled within the archive. But other artifacts are not. This patch keeps the
default behaviour (extracting everything into the same directory), but allows
task authors to specify per-artifact directories to extract into.
The syntax is:
path[>dest]@<task>
The 'dest' value will be a subdirectory of the MOZ_FETCHES_DIR environment
variable.
Depends on D2102.
Differential Revision: https://phabricator.services.mozilla.com/D2166
--HG--
extra : moz-landing-system : lando
Instead of clang 4, which they were the last to use, so remove the
clang 4 toolchain.
--HG--
extra : rebase_source : d03a083e9217aeb6c1d2c91decb978426f0e8d1a
Tom Prince
Marco Castelluccio
Tom Ritter
Gurzau Raul
Nick Thomas
Mike Hommey
Sylvestre Ledru
Jim Chen
Eric Rahm
Andrew Halberstadt
Mike Shal
Boris Chiou
Emilio Cobos Álvarez
Gregory Szorc
dvarga
Nick Alexander
Jacek Caban
Robert Bartlensky
Tudor-Gabriel Vîjială
Sebastian Hengst