This is also fixing bug 31380.

We bump the GCC version to a supported one (9.2.0). The obvious choice
would have been 8.3.0 as we use for our Linux bundles. But, alas, that
one is crashing when cross-compiling Rust for 64bit Windows.

This allows us to switch back to ld.gold as the linker, and fix #31618.

ld.gold fails when we build with debug symbols for linux-i686:

  30:31.20 toolkit/library/symverscript.stub
  30:31.26 toolkit/library/libxul.so
  30:39.58 /var/tmp/dist/binutils/bin/ld.gold.real: internal error in relocate_section, at i386.cc:3684

Updating CMake to the latest stable version as done in the previous
commit solves the reproducibility issue only partly. We need to patch
the code that merges libc++abi.a into libc++.a to get the order in the
merged archive deterministic. The code doing the merging is:

`files = glob.glob(os.path.join(temp_directory_root, '*.o*'))`

Regarding `glob` there is following in the Python docs:

"The glob module finds all the pathnames matching a specified pattern
 according to the rules used by the Unix shell, although results are
 returned in *arbitrary* order." (emphasis mine)

(https://docs.python.org/2/library/glob.html)

The old CMake version built libraries like libc++.a and libc++abi.a in a
non-reproducible way. Using the latest CMake version solves that.

We need to use our own GCC for Linux as the shippped one is too old.

It seems we were a bit too optimistic to pick up FORTIFY_SOURCE support
in mingw-w64 as this breaks our builds. Let's be more conservative and
use what Mozilla is using in their mingw-w64/clang builds.

The underlying node bug got worked around in Mozilla's bug 1500436
and we cherry-pick that patch onto our esr68 branches. Thanks to a
cypherpunk for finding that bugfix.

Changelog update, versions bump

sisbell authored Aug 26, 2019 and Georg Koppen committed Sep 01, 2019

Bug 31389: Update Android Firefox to Build with Clang

sisbell authored Jul 17, 2019 and Georg Koppen committed Sep 01, 2019

Update TOPL version

Georg Koppen authored Aug 25, 2019 and boklm committed Aug 28, 2019

Since r332613 lld has the option of setting the timestamp in PE headers
to `0` which essentially is the behavior of ld's `--no-insert-timestamp`
flag. However, we need a patch for lld's MingW target to pass this
option on in our cross-compilation case, as it would not be available
otherwise.

Georg Koppen authored Aug 23, 2019 and boklm committed Aug 28, 2019

This commit adds a mingw-w64/clang toolchain that is needed for getting
Stylo compiled. The build script follows mostly

https://hg.mozilla.org/releases/mozilla-esr68/file/2f459603370d1d35a56ca4e9cee21f7766bbb832/taskcluster/scripts/misc/build-clang-8-mingw.sh

Exceptions are:

1) We don't build clang in 3 stages but just one like we do for our
macOS cross-compilation toolchain.

2) We are omitting the `DEBUG_FLAGS` (-g -gcodeview) as we plan to
actually ship the resulting build to users, which seems okay (see
bug 1500102).

3) We use a slightly newer libunwind (8.0.0) to better fit to our
clang 8 we deploy.

4) We poke clang harder to compile `i686-w64-mingw32-windres` by
specifying the target explicitly. Using our `var/setarch` trick does not
work anymore for an unknown reason.

Thanks to Martin Storsjö, Jacek Caban, Tom Ritter, and many others for
their help in setting this Windows cross-compilation toolchain up.