I recently discovered that build-tools 23.0.3 doesn't seem to exist on Fedora. Although
I fixed mozboot to download 23.0.1 instead, the builds were still failing because of
configure required 23.0.3.
This seems like an artificial limitation, as building with 23.0.1 seems to work just fine.
This patch will allow either 23.0.1 or 23.0.3.
Note: It would probably better to check for some "minimum" version of build-tools I think
GNU sort has a -V option we could use, but I don't know how cross-platform this is.
MozReview-Commit-ID: 8W0P3yyAHu1
--HG--
extra : rebase_source : 166c1b66962cac6af92c4ce6d3cc1780d9049800
clang-cl accepts #pragma intrinsic like MSVC, but ignores it, unlike
MSVC. We're not concerned with the difference here, so just ignore
the warning.
MozReview-Commit-ID: 3FrVqHpIntq
--HG--
extra : rebase_source : 2609c513f287246e46b436a15d2a786164f91b13
I recently discovered that build-tools 23.0.3 doesn't seem to exist on Fedora. Although
I fixed mozboot to download 23.0.1 instead, the builds were still failing because of
configure required 23.0.3.
This seems like an artificial limitation, as building with 23.0.1 seems to work just fine.
This patch will allow either 23.0.1 or 23.0.3.
Note: It would probably better to check for some "minimum" version of build-tools I think
GNU sort has a -V option we could use, but I don't know how cross-platform this is.
MozReview-Commit-ID: 8W0P3yyAHu1
--HG--
extra : rebase_source : 8e2809327eabd49f681ef42eec9c2f0eb43f1eb8
MSVC allows one to specify -arch:SSE2 and enable all SSE2+ instructions.
clang-cl is pickier and wants you to specify -mssse3.
MozReview-Commit-ID: EqDgoJ5A54V
--HG--
extra : rebase_source : a3d37dcb3c027052a3b81872d9cf08440fc5b963
Android 64-bit doesn't have pthread_cond_timedwait_monotonic_np. So we need check this function. And although we don't turn on sandbox on Android, same define is used in security/sandbox/chromium/base/synchronization/condition_variable_posix.cc.
MozReview-Commit-ID: aeXhNs9Xdj
--HG--
extra : rebase_source : 572d45b14e6447352f0c9235a636ff8feb6c8030
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
It was setting ATTRIBUTE_ALIGNED_MAX which hasn't been used for 6 years
since 590a7be0e60f (bug 556455) removed its only consumer.
MozReview-Commit-ID: HSAql5cUrQH
--HG--
extra : rebase_source : 34193d16b6073c5ad13eb4787b876fc3a9266c2b
Skipping them saves 1.5-2.0s from configure during an artifact build
on Windows.
MozReview-Commit-ID: ArCvrFP9UsD
--HG--
extra : rebase_source : fa580b69d1d96dc0631b626512273302647126f7
Currently, the build scripts enable AltiVec unconditionally on all ppc*
targets. However, there some ppc* targets which do not support AltiVec
instruction set extensions, these are often embedded systems like the
PowerPC e500 or similar which have their own type of instruction set
extensions like SPE. Trying to enable Altivec support on these targets
results in a compiler error, hence we need to add an autoconf test for
AltiVec support before trying to enable it on ppc* targets.
Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
--HG--
extra : rebase_source : 6c4df813d97d95046fd2269c876313ce7591c5cf
Andrew Halberstadt
Nathan Froyd
Mike Hommey
Glenn Randers-Pehrson
Wes Kocher
Chris Manchester
Ryan VanderMeulen
Jared Wein
Makoto Kato
Astley Chen
Phil Ringnalda
Sebastian Hengst
Fernando Jimenez
Franziskus Kiefer
Andrew Comminos
Gregory Szorc
Gian-Carlo Pascutto
John Paul Adrian Glaubitz