- 23 Sep, 2019 2 commits
-
-
Georg Koppen authored
-
boklm authored
-
- 20 Sep, 2019 1 commit
-
-
boklm authored
This is also fixing bug 31380.
-
- 18 Sep, 2019 1 commit
-
-
Georg Koppen authored
-
- 17 Sep, 2019 1 commit
-
-
Georg Koppen authored
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.
-
- 16 Sep, 2019 1 commit
-
-
boklm authored
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
-
- 13 Sep, 2019 3 commits
-
-
Georg Koppen authored
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)
-
Georg Koppen authored
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.
-
Georg Koppen authored
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.
-
- 11 Sep, 2019 4 commits
-
-
Georg Koppen authored
-
boklm authored
-
boklm authored
-
boklm authored
-
- 10 Sep, 2019 1 commit
-
-
boklm authored
-
- 09 Sep, 2019 2 commits
-
-
Georg Koppen authored
-
Georg Koppen authored
-
- 08 Sep, 2019 1 commit
-
-
Georg Koppen authored
-
- 06 Sep, 2019 1 commit
-
-
- 05 Sep, 2019 1 commit
-
-
Georg Koppen authored
-
- 04 Sep, 2019 1 commit
-
-
Georg Koppen authored
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.
-
- 03 Sep, 2019 1 commit
-
-
Georg Koppen authored
-
- 02 Sep, 2019 7 commits
-
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
-
Georg Koppen authored
Changelog update, versions bump
-
- 01 Sep, 2019 4 commits
-
-
Bug 31389: Update Android Firefox to Build with Clang
-
Update TOPL version
-
-
Georg Koppen authored
-
- 30 Aug, 2019 1 commit
-
-
- 29 Aug, 2019 1 commit
-
-
- 28 Aug, 2019 6 commits
-
-
Georg Koppen authored
-
-
-
-
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.
-
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.
-