summaryrefslogtreecommitdiff
path: root/www/firefox/files/patch-bug1479540
diff options
context:
space:
mode:
authorJean-Sébastien Pédron <dumbbell@FreeBSD.org>2018-09-16 07:57:08 +0000
committerJean-Sébastien Pédron <dumbbell@FreeBSD.org>2018-09-16 07:57:08 +0000
commitaa8061d1c1a2f583f73aab0d631dec7a7d8afa0e (patch)
tree4e8277d49f4d232f79147d6a527ee0123f20b944 /www/firefox/files/patch-bug1479540
parent- update MASTER_SITES (diff)
lang/rust: Update to 1.29.0
Release notes: * https://blog.rust-lang.org/2018/07/20/Rust-1.27.2.html * https://blog.rust-lang.org/2018/08/02/Rust-1.28.html * https://blog.rust-lang.org/2018/09/13/Rust-1.29.html Up to and including Rust 1.27.x, the Rust build system shelled out to a configure script to detect the presence and usability of libunwind. Since Rust 1.28.0, it's using a static result in a `build.rs` file and expects libunwind to be used. It was not the case on FreeBSD so far, so we need a patch to this `build.rs` to disable that. We still need to study if the FreeBSD port should use libunwind and what to do with this patch. But this problem prevented the update to Rust 1.28.0 already, so enough delay. The update also comes with a patch to a few `USE_GECKO`-based ports such as Firefox [1]. Their configure script has some asumptions on the output of `rustc --print target-list` which are not true anymore. The patch was already committed upstream. The aarch64 version is still marked as BROKEN because I didn't find the time to work on it. As a consequence, there is also no aarch64 bootstrap for Rust 1.29.0. PR: 229826 Approved by: jbeich [1] Obtained from: https://bugzilla.mozilla.org/show_bug.cgi?id=1479540 [1] Differential Revision: https://reviews.freebsd.org/D17178
Notes
Notes: svn path=/head/; revision=479877
Diffstat (limited to 'www/firefox/files/patch-bug1479540')
-rw-r--r--www/firefox/files/patch-bug147954041
1 files changed, 41 insertions, 0 deletions
diff --git a/www/firefox/files/patch-bug1479540 b/www/firefox/files/patch-bug1479540
new file mode 100644
index 000000000000..e97a94cf8fc0
--- /dev/null
+++ b/www/firefox/files/patch-bug1479540
@@ -0,0 +1,41 @@
+# HG changeset patch
+# User Chris Manchester <cmanchester@mozilla.com>
+# Date 1533063488 25200
+# Node ID 36f4ba2fb6f5139b7942e81554190354da1f369a
+# Parent ff18e94c90460faa9cca8ff39a0ea4876b0c2039
+Bug 1479540 - Accept "triplet" strings with only two parts in moz.configure. r=froydnj
+
+MozReview-Commit-ID: 7pFhoJgBMhQ
+
+--- build/moz.configure/init.configure
++++ build/moz.configure/init.configure
+@@ -587,17 +587,26 @@ option('--target', nargs=1,
+ @imports(_from='__builtin__', _import='KeyError')
+ @imports(_from='__builtin__', _import='ValueError')
+ def split_triplet(triplet, allow_unknown=False):
+ # The standard triplet is defined as
+ # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
+ # There is also a quartet form:
+ # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
+ # But we can consider the "KERNEL-OPERATING_SYSTEM" as one.
+- cpu, manufacturer, os = triplet.split('-', 2)
++ # Additionally, some may omit "unknown" when the manufacturer
++ # is not specified and emit
++ # CPU_TYPE-OPERATING_SYSTEM
++ parts = triplet.split('-', 2)
++ if len(parts) == 3:
++ cpu, _, os = parts
++ elif len(parts) == 2:
++ cpu, os = parts
++ else:
++ die("Unexpected triplet string: %s" % triplet)
+
+ # Autoconf uses config.sub to validate and canonicalize those triplets,
+ # but the granularity of its results has never been satisfying to our
+ # use, so we've had our own, different, canonicalization. We've also
+ # historically not been very consistent with how we use the canonicalized
+ # values. Hopefully, this will help us make things better.
+ # The tests are inherited from our decades-old autoconf-based configure,
+ # which can probably be improved/cleaned up because they are based on a
+
+