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
Subtly, as toolkit/moz.configure happens before toolchain tests, we
can't set MOZ_SERVO_LIBS from there. And toolkit/moz.configure is
not always included either, making things awkward to do in python
configure.
OTOH, there's only one place where MOZ_SERVO_LIBS is used, and the
corresponding setup can actually be done there (in moz.build) instead.
I think we shouldn't shy away from moving things this way.
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
Also, now that we're using modern C++11 compilers, we can just rely on
static_assert, instead of the pile of macros used in the autoconf test.
--HG--
extra : rebase_source : 85d507da653d07e6527a971082277486e3502ea2
Now that we compile with cargo, we don't have fine-grained control over
the build flags used via environment variables detected in configure or
set in config.mk. We should just remove that dead code so nobody trips
over it.
Functions deprecated in GTK3 are often used for compatibility with GTK2
builds.
MozReview-Commit-ID: F220phw3wVO
--HG--
extra : rebase_source : 128e885652b184c5a7916378d9cebb067ab97eb0
The only use of this variable is to override NSINSTALL, and its value is
the same as NSINSTALL_PY.
While here, remove the outdated NSINSTALL_NATIVECMD that was used for
pymake.
--HG--
extra : rebase_source : b871fbb409836a17cb8d71cd1e5ddc9d5ad3f49f
Nothing is using MAKE in old-configure, and it was not AC_SUBST'ed, so
we don't need to set it when it's not set in the environment already.
--HG--
extra : rebase_source : 9a525517808db87add72989ab9f43a135c0cc776
Since bug 1259382, CC and CXX are always set, so we can stop
falling back to cl on Windows, and clang on OSX in compiler-opts.m4.
Also, we were actively rejecting GCC on OSX because it was based on
GCC 4.2 and known to be broken, but that test predates our requirement
for more recent versions of GCC, which would fail configure anyways.
So just remove that GCC test. Building with a modern GCC from macports
or wherever might actually work anyways.
Finally, remove target bit-width mismatch with the compiler as it's
handled in python configure since bug 1288313.
--HG--
extra : rebase_source : 9968028cc4e9c197b72136037a7298be10cc139a
The base compiler check in python configure does some preprocessing,
which ensures the compiler works to some extent. Autoconf used to have
a more complete test, doing a compile/link. We do have plenty of tests
afterwards that do that anyways, but it's better if we fail early if
the toolchain fails somehow.
This refactors try_compile such that the *_compiler variable themselves
can be used to trigger compiler tests. Eventually, we'll want something
similar for preprocessing and possibly other invocations.
This also removes similar tests from build/autoconf/toolchain.m4 and
old-configure.in.
--HG--
extra : rebase_source : 4f6f84e5ad220386e9edf82d19cc2cd6c1f4c43e
Python configure "environment variables" can be passed as actual
environment variables, but can also be passed as command line arguments
(unless they also make it to old-configure, which doesn't support that).
Passing empty environment variables is broken in msys2/cygwin: the
subprocess doesn't see the environment variable being set, so it can't
tell the difference between "not set" and "set to nothing", which has a
different meaning for python configure environment variables.
Currently, JS_STANDALONE is passed this way. Passing it as a command
line argument makes it properly passed down to the subconfigure.
--HG--
extra : rebase_source : d4ebaf9d626902166c3861ee9d6141255658194f
Franziskus Kiefer
Carsten "Tomcat" Book
Nicholas Hurley
Eugen Sawin
Kai Engert
Gerald Squelart
Chris Manchester
Wes Kocher
Andrew Halberstadt
Nathan Froyd
Mike Hommey
Glenn Randers-Pehrson
Ryan VanderMeulen
Jared Wein
Makoto Kato
Astley Chen
Phil Ringnalda
Sebastian Hengst
Fernando Jimenez
Andrew Comminos
Gregory Szorc
Gian-Carlo Pascutto
John Paul Adrian Glaubitz
Alexandre Lissy
Nathan Froyd
Karl Tomlinson
Frank-Rainer Grahl
Nathan Hakkakzadeh