This commit also removes dwarf-exceptions from the x64 build.
sjlj exceptions are needed on x86 because there is a bug currently involving
SEH exceptions on x86. However on x64 there is not, so we can use the
default SEH and get rid of dwarf exceptions. Additionally, to use SEH
exceptions, we need to -fuse-cxa-atexit
Differential Revision: https://phabricator.services.mozilla.com/D7759
--HG--
extra : moz-landing-system : lando
This commit also removes dwarf-exceptions from the x64 build.
sjlj exceptions are needed on x86 because there is a bug currently involving
SEH exceptions on x86. However on x64 there is not, so we can use the
default SEH and get rid of dwarf exceptions. Additionally, to use SEH
exceptions, we need to -fuse-cxa-atexit
Differential Revision: https://phabricator.services.mozilla.com/D7759
--HG--
extra : moz-landing-system : lando
The cctools-port linker links against libraries from clang (for LTO),
which have different SONAMEs depending on the clang version. Which means
the linker needs to be used along the same version of clang it was built
against. Thus we also make it depend on linux64-clang-7.
But changing the dependency is not enough, cf. bug 1471905, so also
touch its build script, which it turns out, we need to do anyways
because llvm-dsymutil was renamed to dsymutil.
Relatedly, all toolchains that are built using cctools-port need to use
linux64-clang-7 too.
Building compiler-rt 7 with the OSX 10.11 SDK fails because of some
newer APIs being used in compiler-rt for xray, but this is not a feature
we use, so disable that.
Differential Revision: https://phabricator.services.mozilla.com/D6766
--HG--
rename : build/build-clang/clang-6-macosx64.json => build/build-clang/clang-7-macosx64.json
rename : taskcluster/scripts/misc/build-clang-6-linux-macosx-cross.sh => taskcluster/scripts/misc/build-clang-7-linux-macosx-cross.sh
extra : moz-landing-system : lando
This incorporates some fixes for ccache, icecream, and a better display
output (decreasing count instead of an increasing count). It may also
let us experiment with incremental rust support, though I think that
feature still needs some more work.
MozReview-Commit-ID: 7zPGiL9Ob6N
Differential Revision: https://phabricator.services.mozilla.com/D7152
--HG--
extra : moz-landing-system : lando
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
