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 is a fairly straightforward port of the AS tool checks from old-configure
to toolchain.configure. AS is a little quirky in that we currently do a
normal-looking check for it, but then override that value to be the C compiler
for non-Windows builds, and ml[64]/armasm64 for Windows builds.
After migrating those checks, the only things left in the MOZ_DEFAULT_COMPILER
macro in compiler-opts.m4 were some unused bits, so I removed them:
* Setting of CPP/CXXCPP, which are set in toolchain.configure now
* Setting HOST_LDFLAGS to empty, which doesn't seem particularly useful.
There was also a quirky old test that the assembler was ml[64] when js-ctypes
is enabled that I removed, I don't think it provides any value since this
patch will ensure that we're using the right assembler for Windows builds.
BUILD_TOOLS was only ever used for things that another variable provides
equally well. Removing BUILD_TOOLS means that we can remove win_srcdir
and WIN_TOP_SRC as well.
We were already always enabling it on builds with frame pointers on
Android. We now extend this to builds without frame pointers, helping
with client-side stacktracing for crashes.
It's also the default on many platforms, such as x86-64, whether frame
pointer are enabled or not and on x86 with GCC. Somehow, it's not the
case for x86 with clang, so this makes clang builds the same as GCC
builds in that regard.
On ARM, we were always omitting frame pointers because of a GCC bug, but
we've not been using GCC for Android builds for a long time (and the GCC
bug was actually fixed in 4.7 and backported to 4.6, making it fixed in
all versions of GCC we support).
Differential Revision: https://phabricator.services.mozilla.com/D6110
--HG--
extra : moz-landing-system : lando
Last attempt, a few years ago, blatantly failed because nautilus (the
GNOME file manager) can't start PIE executables, which look like shared
libraries, and that it thus considers not being executables.
Downstreams don't actually have the problem, because users won't be
launching Firefox from a file manager, but for mozilla.org builds, it is
a problem because users would download, then extract, and then likely
try to run the Firefox executable from a file manager.
So for mozilla.org builds, we still need to find a way around the
nautilus problem.
A .desktop file could be a solution, but .desktop files have not
actually been designed for this use case, which leads to:
- having to use an awful one-liner shell wrapper to derive the path
to the executable from that of the .desktop file,
- not even being able to associate an icon,
- the .desktop file not being copiable to a location where .desktop
files would normally go, because it would then fail to find the
executable.
Another possibility is to go back to using a shell wrapper, but that's
not entirely appealing.
What we chose here is similar, where we have a small `firefox` wrapper
that launches the real `firefox-bin` (which is still leftover from those
old times where we had a shell wrapper, for reasons).
The small `firefox` wrapper is a minimalist C executable that just
finds the path to the `firefox-bin` executable and executes it with the
same args it was called with. The wrapper is only enabled when the
MOZ_NO_PIE_COMPAT environment variable is set, which we only take into
account on Linux. The variable is only really meant to be used for
mozilla.org builds, for the nautilus problem. Downstreams will just pick
the default, which is changed to build PIE.
On other platforms, PIE was already enabled by default, so we just
remove the --enable-pie configure flag.
Differential Revision: https://phabricator.services.mozilla.com/D5109
When building executables as PIE, and because we use -Bsymbolic, which
symbols are exported from an executable varies based on the libraries
it's directly linked against, to fulfil their symbol needs. So when a
library depends on e.g. ASAN runtime symbols, and the linker finds that,
it will keep those ASAN symbols in the executable for the library. And
drop the other, unused symbols.
But when the executable then dlopen()s a library (e.g. shlibsign loading
libfreebl) that uses another set of ASAN symbols, including symbols that
none of the direct dependencies of the executable need, dlopen() fails
because of the missing symbols.
It's not currently an apparent problem because we don't enable PIE, and
we build Gecko executables with -rdynamic already (for mozjemalloc). But
we don't build non-Gecko executables this way (like shlibsign).
Differential Revision: https://phabricator.services.mozilla.com/D5108
At least, when that combination doesn't work. This requires passing the
LTO flags to the compiler invocations for the test, which in turn
requires actually calling the linker directly on Windows, instead of
directly through the compiler, as when actually building.
Differential Revision: https://phabricator.services.mozilla.com/D4739
--HG--
extra : moz-landing-system : lando
Back before expandlibs was removed in bug 1429875, not using list files
was supported, but nowadays, it just leads to errors like the following:
*** No rule to make target 'libfake_so.list', needed by 'libfake.so'. Stop.
We might as well error out during configure, rather than much later
during the build.
Differential Revision: https://phabricator.services.mozilla.com/D4738
Back before expandlibs was removed in bug 1429875, not using list files
was supported, but nowadays, it just leads to errors like the following:
*** No rule to make target 'libfake_so.list', needed by 'libfake.so'. Stop.
We might as well error out during configure, rather than much later
during the build.
Differential Revision: https://phabricator.services.mozilla.com/D4738
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
The media/libpng/moz.build file overrides the C standard used via
-std=c89, per bug 1371266, which conflicts with the use of the
arm_neon.h header: compilation fails on the inline keyword, which didn't
exist in C89. We thus "bump" to the GNU89 standard, which is C89+GNU
extensions, including inline.
--HG--
extra : rebase_source : fe93a13e3bef8888e1874d2e94a6d8ef396aaf83
It's the *compile*SdkVersion that needs to match the installed Android SDK plat-
form in order to be able to build an app, whereas the *target*SdkVersion is
merely a compatibility flag.
Since the received wisdom is that targetSdkVersion should be <= compileSdk-
Version and Android Studio is also showing a warning to that effect if you
modify the build.gradle of a small sample app accordingly, I've also added a
corresponding configure check of our own to enforce this.
MozReview-Commit-ID: F2RZemChFrm
--HG--
extra : rebase_source : cf4f6256baa4446d673b94d97f9497f93d7917ff
André Bargull
Nick Alexander
Cosmin Sabou
David Major
Guillaume GARDET
shindli
Ted Mielczarek
Nathan Froyd
Thomas P.
Andreea Pavel
arthur.iakab
Mike Hommey
Jim Chen
Tom Ritter
Sebastian Hengst
Jan Beich
Henri Sivonen
Mike Hommey
Andi-Bogdan Postelnicu
Jan Henning