This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
The clang_rt.builtins lib files produced by the 1stage build do not include
functions necessary for 128bit integers. This functionality is required by the
OpenPGP libraries that Thunderbird is using, specifically Botan's bigint module.
When compiler-rt is built with MSVC, these functions are not included
by design.
Differential Revision: https://phabricator.services.mozilla.com/D71785
Currently the linux64-clang-9-win-cross toolchain depends on the win64-clang-cl toolchain for a few files. This causes very long lead times when toolchains are rebuilt, because of the un-parallelizable chain of tasks win64-clang-cl -> linux64-clang-9-win-cross -> builds.
As a partial mitigation, this patch adds a single-stage clang-cl build for consumption by the cross toolchain. It's not a very high quality build, but good enough for the purpose it serves, while being faster to build.
Differential Revision: https://phabricator.services.mozilla.com/D70254
--HG--
rename : build/build-clang/clang-win64.json => build/build-clang/clang-win64-1stage.json
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
The `linux64-clang-9-cross` toolchain was forked from `linux64-clang-9` in https://hg.mozilla.org/integration/autoland/rev/ca923afe3ed4 in order to pick up a patch for Windows compilation.
This is no longer necessary for two reasons:
1. Windows builds stopped depending on that patch in bug 1608460.
2. Even if we still needed that patch, the `linux64-clang-9` toolchain gained all of the Windows patches in bug 1618473.
Therefore the `clang-dist` task can go back to using unmodified `linux64-clang-9`.
Differential Revision: https://phabricator.services.mozilla.com/D70263
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
This creates a new toolchain artifact that repacks a combination of the
linux64-clang compiler along with parts of the win64-clang-cl compiler.
This has multiple advantages:
- It removes some convoluted parts of build task definitions (limiting
that to only occur on the win-cross toolchain itself).
- It simplifies the build setup by not requiring to prepare for where
clang-cl.exe is.
- It speeds up getting compiler artifacts because the win64-clang-cl
artifact is very large (due to there not being a llvm shared library)
and bzipped, which is slow to decompress. Here, we only take what we
need for the cross builds.
- It adds the runtime files that e.g. PGO will require, and that
linux clang-cl insists lives in the clang directory, not the
win64-clang-cl one, and that would require some convoluted setup to make
it work with the two separate toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D66543
--HG--
extra : moz-landing-system : lando
We can remove our backported objcopy patches, we'll need to update
llvm-mingw for toolchain fixes, and we need to add binutils to compile
this newer version of clang because the system binutils is too old.
Differential Revision: https://phabricator.services.mozilla.com/D50152
--HG--
rename : build/build-clang/clang-8-mingw.json => build/build-clang/clang-9-mingw.json
rename : taskcluster/scripts/misc/build-clang-8-mingw.sh => taskcluster/scripts/misc/build-clang-mingw.sh
extra : moz-landing-system : lando
We can remove our backported objcopy patches, we'll need to update
llvm-mingw for toolchain fixes, and we need to add binutils to compile
this newer version of clang because the system binutils is too old.
Differential Revision: https://phabricator.services.mozilla.com/D50152
--HG--
rename : build/build-clang/clang-8-mingw.json => build/build-clang/clang-9-mingw.json
rename : taskcluster/scripts/misc/build-clang-8-mingw.sh => taskcluster/scripts/misc/build-clang-mingw.sh
extra : moz-landing-system : lando
llvm-mingw has found a way to build libssp indepdendent of gcc which
is great. We set up some stuff to support that and then use that method.
Differential Revision: https://phabricator.services.mozilla.com/D56248
--HG--
extra : moz-landing-system : lando
We need this for "full" C++17 support (everything is supported, but some
C++17 features still have bugs) and this change also brings Linux into
parity with our Mac requirements.
MANUAL PUSH: build toolchains on inbound to avoid clogging autoland
Differential Revision: https://phabricator.services.mozilla.com/D51450
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change also
means that the newly-built clang (and associated tools) links against
GCC 7's libstdc++, but we set RPATH or similar appropriately, so there
shouldn't be issues stemming from that.
MANUAL PUSH: toolchain patches are requested to land on inbound
Differential Revision: https://phabricator.services.mozilla.com/D41251
With clang-8 sources, this task was already pretty close to the limit with typical times of 54-58 minutes.
In clang-9, enough new code was added that we're seeing frequent intermittent timeouts. Even the few successful builds come in just under the wire at 60 minutes.
Note for sheriffs, if the clang-9 update gets backed out, this patch can stay, we'll need it anyway.
Differential Revision: https://phabricator.services.mozilla.com/D47288
--HG--
extra : moz-landing-system : lando
The aarch64 cross toolchain is unused otherwise. The aarch64-linux
builds also exist for the express purpose of eventually standing up some
kind of fuzzing/ccov build, so we might as well start using a toolchain
that supports those use cases.
Differential Revision: https://phabricator.services.mozilla.com/D45210
--HG--
extra : moz-landing-system : lando
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.
Differential Revision: https://phabricator.services.mozilla.com/D41251
--HG--
extra : moz-landing-system : lando
We need this change so that the newly-built clang will have
C++17-compatible libstdc++ headers installed. I believe this change
also means that the newly-built clang (and associated tools) links
against GCC 7's libstdc++, but we set RPATH or similar appropriately, so
there shouldn't be issues stemming from that.
Differential Revision: https://phabricator.services.mozilla.com/D41251
--HG--
extra : moz-landing-system : lando
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
They are now all very similar, and there are only a few variations.
Differential Revision: https://phabricator.services.mozilla.com/D40365
MANUAL PUSH: avoid closing autoland while toolchains are rebuilt.
Analogously to the existing `linux64-clang-8-android-cross` build, this
build is a linux x86-64 build with runtime library support for aarch64.
Depends on D28405
Differential Revision: https://phabricator.services.mozilla.com/D28406
--HG--
extra : moz-landing-system : lando
Narcis Beleuzu
Mike Hommey
Csoregi Natalia
Rob Lemley
David Major
Andi-Bogdan Postelnicu
Mihai Alexandru Michis
Cosmin Sabou
jayati
Tom Ritter
Andreea Pavel
Ricky Stewart
Nathan Froyd
Tom Prince
Ciure Andrei
Chris Manchester
Brindusan Cristian
Razvan Maries
Christian Holler