At the same time, remove HOST_LD. It was only used for MSVC builds,
which don't support cross-compile anyways, so we can, at least for now,
use LINK for both host and target.
--HG--
extra : rebase_source : 9ee9e7e1bd3edefc043fa63d5c03f2a242f76982
Compilers other than GCC, clang and MSVC have not been supported for a
while, and have been explicitly rejected since bug 1259382.
There are a few branches in old-configure that are taken for
non-GCC/clang compilers, but all of them are later overwritten by the
MSVC setup. So we just remove those.
--HG--
extra : rebase_source : 65c0b1223afeff3042089c5ba4457392c79bb13a
In some cases, on OSX, python's `os.path.realpath` and shell's `pwd -P`
don't agree on the case of paths on case-insensitive filesystems.
So make everyone agree by using the value from python configure.
--HG--
extra : rebase_source : 4d26bf30f3f125c4f75d42f79d8a80a4a0bf11ec
Previously PSM would load EV information on-demand (i.e. just before verifying a
certificate). This simplifies this operation, removes a dubious optimization
(loading the EV information on another thread while opening a network
connection), and relocates the loading operation to when we are likely to have
good disk locality (i.e. when we've just loaded the built-in roots module).
This also removes the now-unused MOZ_NO_EV_CERTS build flag.
MozReview-Commit-ID: 8Rnl4ozF95V
--HG--
extra : rebase_source : 5b2e76079c256f7e3c55b1d4ec0d9f654fec44f6
Previously PSM would load EV information on-demand (i.e. just before verifying a
certificate). This simplifies this operation, removes a dubious optimization
(loading the EV information on another thread while opening a network
connection), and relocates the loading operation to when we are likely to have
good disk locality (i.e. when we've just loaded the built-in roots module).
This also removes the now-unused MOZ_NO_EV_CERTS build flag.
MozReview-Commit-ID: 8Rnl4ozF95V
--HG--
extra : rebase_source : 344b68c81af1ed3fb038e4e96c3c50e939d32c3d
64-bit Windows builds that use clang-cl need -mssse3 specified, just
like the 32-bit builds.
MozReview-Commit-ID: KAYXYAAw46I
--HG--
extra : rebase_source : c882da5408c6e081b9564c859e73eccc5671287b
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
Its value was only used in a couple C++ files, and a corresponding value
can be gotten directly from including winsdkver.h.
--HG--
extra : rebase_source : 618f1eb2ee0243a6c1c652ccce45b2aeba959edf
The best kind of patch: bulk deletion. This removes two separate but
similar build flags, and an unsupported integration piece. The first
packaged Fennec's resources into an ill-defined GeckoView archive; the
second built on the first to produce an Android ARchive for external
consumption. Neither of these artifacts are supported or have
consumers; in fact, they mislead potential consumers, since they're
known to be broken. The Gradle build work under the --with-gradle
flag, and significant follow-up, is the path forward if Mozilla wants
to invest in packaging GeckoView on Android for external consumption.
That is, rather than hacking together AAR files, we'll use the
well-supported Gradle mechanisms for building and publishing such
libraries.
MozReview-Commit-ID: 4Z1jJ8z0cyJ
--HG--
extra : rebase_source : b8e65f39c286313fe8963bf3832d9b6977ef188f
Ryan VanderMeulen
Mike Hommey
Chris Peterson
Astley Chen
Haik Aftandilian
Ted Mielczarek
Valentin Gosu
Sebastian Hengst
Henri Sivonen
Masatoshi Kimura
Michelangelo De Simone
Manish Goregaokar
Eugen Sawin
Chris Manchester
David Major
David Keeler
Michelangelo De Simone
Kai Engert
Carsten "Tomcat" Book
Jan Beich
Wes Kocher
Brad Lassey
Ehsan Akhgari
Kris Maglione
Xidorn Quan
Nathan Froyd
Franziskus Kiefer
Nicholas Hurley
Gerald Squelart
Andrew Halberstadt
Glenn Randers-Pehrson
Jared Wein
Makoto Kato
Phil Ringnalda
Fernando Jimenez
Andrew Comminos
Gregory Szorc
Gian-Carlo Pascutto
John Paul Adrian Glaubitz
Alexandre Lissy
Nathan Froyd
Karl Tomlinson
Frank-Rainer Grahl
Nathan Hakkakzadeh
Nick Alexander