Interestingly, the change makes one configure test have a different
result (localeconv ends up being found when it used not to be found),
but the result of that check is actually not used on Windows because we
set HAVE_LOCALECONV manually.
Differential Revision: https://phabricator.services.mozilla.com/D25902
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
Remove the version check for WINDRES, because, as per bug 454112, it
didn't actually work, and, making it work actually causes problems
because llvm's windres, used with mingw clang, has version 0.1.
Differential Revision: https://phabricator.services.mozilla.com/D15070
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
The GNU_AS check in old-configure depended on running with the value
of $AS before it gets reset to just be the C compiler, which breaks when
we move setting AS into moz.configure.
This patch moves the GNU_AS check to toolchain.configure and changes it
so that it works when the assembler is the C compiler. We do have to
fix things slightly for clang, because the previous check was
succeeding, but not because of clang: it was detecting the presence of
"GNU" in the output for GNU ld/gold and a message about the GNU GPL.
This forces the linker ot use libatomic with clang on x86 (not only Android)
and forwards the intent to use libatomic to the shell's moz.build.
--HG--
extra : rebase_source : 0c803a3e11efcad3f17a462c2d38e85ec6cb556a
NDK r15+ clang changed the code generation strategy for the __atomic_*
intrinics such that using them with 64-bit types now requires linking
with libatomic. Our current configure tests for libatomic doesn't catch
this, because the std::atomic implementation is such that it doesn't
require an external library, even for 64-bit types, whereas the
__atomic_* intrinsics do. The safest thing to do is to force this
configure check to always return true when we are compiling for
x86/Android with clang.
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.
--HG--
extra : rebase_source : c60d1d6e39b6bd2a377516687affd9b8932ebc12
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
We were unconditionally adding them, now actually check what the
compilers default to and add the flags if they are necessary.
This will, in the future, allow finer grained policy changes, where
we can decide that C++11 and C++14 are fine, downgrading compilers
that do C++17, etc.
At the same time, we improve things slightly by deriving HOST_CC from CC
in a smarter way, as well as CXX from CC, which we weren't doing
previously.
Many related things are not moved at the same time to keep the patch
somehow "small".
In bug 1254861, we unsupported clang < 3.3, picking 3.3 essentially
because that's the smallest version we had on automation. Bug 1254854
changed that, and the smallest version on automation is now 3.5.
Now, the motivation to unsupport an old version of clang again is that
recent versions don't have the problem with __float128 used in libstdc++
headers (bug 654493). In fact, starting with clang 3.4, the hack we have
in place is not necessary.
So let's just drop support for clang 3.3 instead of keeping that hack
around longer.
As mentioned in bug 1254854, Ubuntu 12.04 LTS has clang 3.4 packages.
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Note that this removes force-setting cross_compiling to yes in
old-configure, which wasn't working because every AC_TRY_COMPILE
resets it with $ac_cv_prog_cc_cross or $ac_cv_prog_cxx_cross.
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
I tested locally that both checks give the expected error if I
temporarily change the != to an =.
--HG--
extra : transplant_source : %01N%B9%8B%BC%1E%07%D6%AE%BA2%7B%87%FB%25Y%19%B6%A9%D3
The duplication of the code higher up is a little bit annoying, but I
don't see an easy way to avoid that. It's also still quite far from
duplicating everything.
I tested locally with a Fennec build that if I bump the requirement from
4.6 to 4.9, I get the expected build error.
--HG--
extra : transplant_source : D%D3%FE%169%05%D0X%F3KK%17%9EW%88%BCs%9B%86%5D
It looks like overwriting AS here is not intentional. Before this patch,
it is impossible to override AS through mozconfig for anything that runs
past this stage in configure.
