It's enabled by default as of clang 7 with -Oz on aarch64 (that is,
afaict, the only platform where it's enabled), and regresses our
performance on speedometer.
Differential Revision: https://phabricator.services.mozilla.com/D12394
--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 is a straightforward port of MIDL_FLAGS from old-configure to
moz.configure. The only behavioral change is that it removes support for
prepending MIDL_FLAGS from the environment in configure, but I doubt anyone
uses that.
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.
Some build flags are being passed by the build system: they're passed in a text
file called extra-bindgen-flags.in that's filled at configure time.
Other flags have to be inferred from the current target/host combination, in
Cranelift's build script directly. This is mostly cargo-culted from the
ServoBindings.toml file, and should probably be merged in the build system at
some point.
Some Windows-specific adjustments were needed to provide access to libclang for
bindgen support, by adding clang-cl to the plain Spidermonkey Windows builds.
--HG--
extra : rebase_source : 0bda40b1d1eb38c2657593f094c951013711d00a
extra : histedit_source : aad930a5f9099e299d385ae4de2deb81aed9b6d5
It's nicer to have all that logic in one place, and to be able to common
up the Unix-y flags setting. The Makefile constructs in string values
is gross, but it's no worse than we had before.
clang doesn't recognize --enable-stdcall-fixup as an option. We needed this for the
mingw-gcc build (added in Bug 787653) because gcc had difficulty dealing with
Angle's symbol linking
Differential Revision: https://phabricator.services.mozilla.com/D6072
--HG--
extra : moz-landing-system : lando
Currently mozconfig.cache overrides a few build options for sccache.
This patch moves them into toolchain.configure so that the build system
will set them properly when sccache is in use. Additionally,
{CC,CXX}_WRAPPER are set in config.mk, so just avoid setting them when
sccache is in use.
On 64-bit Android, `pthread_cond_timedwait_monotonic_np` is only
available for API 28+. The issue is, even though the NDK header does not
define `pthread_cond_timedwait_monotonic_np` for API 27 and below, the
NDK library _does_ include the function (in order to support builds
targeting API 28+).
During our configure test, the compiler only emits a warning about
`pthread_cond_timedwait_monotonic_np` being undefined, but linking
succeeds because the function is present in the library. Because linking
succeeds, the test inadvertently passes. This patch adds a '-Werror'
flag to the compilation, so the warning turns into an error to make the
test fail.
Differential Revision: https://phabricator.services.mozilla.com/D4482
AArch64 Windows includes the necessary DLL in its default configuration,
so we don't need to bother locating it in the SDK. We made need to
distribute an updated version that won't by on the system by default,
though, so we need some extra checking.
BFD ld's --build-id means --build-id=sha1, but with lld it means
--build-id=fast. Both support the explicit --build-id=sha1, so use that.
Gold supports --build-id=sha1 too.
ld64, used for mac builds doesn't support neither --build-id=sha1 nor
--build-id.
-DEBUGTYPE:CV, -NXCOMPAT, and -DYNAMICBASE are on by default in both link.exe and lld-link.
--HG--
extra : rebase_source : 3b50b88bb8ac9257689df2e10146906ef9962b08
The Rust dependency in Firefox has been limited to Firefox builds by
virtue of having the Rust check in a Firefox-specific location,
toolkit/moz.configure. For JS to start depending on Rust, we need to
move that check to a location where a standalone JS engine build will
pick up the Rust check.
Because we have no linking configure test in python configure (yet), we
just make old-configure tests use LINKER_LDFLAGS, and make those flags
added to LDFLAGS by old-configure at the same time.
--HG--
extra : rebase_source : 80ab7c5021c7ddd1b53d58ef76cd4372a524d3cb
clang seems to have decided that a new warning,
-Wused-but-marked-unused, is useful. For the purposes of our codebase,
where we add __attribute__((unused)) explicitly to avoid warnings about
unused things, this new warning is useless. The new warning is also
quite noisy, given that we have unused things in commonly-used headers
like Assertions.h. So disable the warning.
MOZ_WIDGET_TOOLKIT can be used for platform choice for Gamepad. Need
to leave linux header check in configure for now.
MozReview-Commit-ID: VT7T2KmLts
--HG--
extra : rebase_source : 02e7a23311c65fccffb1375a3adf8980d3d6031c
Some configurations of SpiderMonkey wind up producing C++ switch statements of
the form
switch (..) {
default: break;
}
We hoped that they would simply be optimised out without comment. But MSVC
warns about the lack of non-default cases, which then are escalated into
errors, causing the build to fail. This commit simply disables that warning
feature when building with MSVC.
--HG--
extra : rebase_source : 468022d30cdaf483aaa64fc7aa9dd1308fbc7335
We use -O2 for js (because we can) and we use -O1 for the root because there is an x86 compiler bug
that is not immediately bypassable
MozReview-Commit-ID: CnDk2ko3jfo
--HG--
extra : rebase_source : bf889ab143bbf9480a261b06000d62cf0e1af8cc
-TC specifies 'treat all inputs at C files' which breaks things when you
specify a @list file of inputs.
During configure, -TP is required for C++ configure checks (although we
could probably make it smart and not need it at all), but -TC does not seem
to be required.
MozReview-Commit-ID: DNA8vUMdIXb
--HG--
extra : rebase_source : 523c6d815adf55c834fd858b10010123f86b25f6
MOZ_UPDATE_CHANNEL is meant to set the channel to use for the updater,
and nothing else. It's not an indicator of which branch we're building
on and it's not an indicator of whether it's a developer build or a CI
build. The latter seems to be what it's used for for A11Y_LOG, so use
DEVELOPER_OPTIONS instead.
--HG--
extra : rebase_source : 48822af1e4af444e00c89859c51c01c57d130248
This option does nothing if it's provided, and things will probably
break in some most peculiar manner if somebody uses --without-pthreads.
Given that neither outcome is useful, we should remove the option.
target value of Anndroid/arm is arm-unknown-linux-androideabi, so arm-*-linux*
matches on android/arm and MOZ_CRASHREPORTER is unset as default option.
Since taskcluster's build adds --enable-crashrepoter as default, we should set
it as developer's default too.
MozReview-Commit-ID: 8V6sWAN07F9
--HG--
extra : rebase_source : b4a26eea2d53eb8b53cc49e972d9d41b32d4ec97
We use a wrapper script when compiling with MSVC to parse the
/showIncludes output and thereby generate a Makefile dependency
fragment. This fragment enables us to do correct and faster incremental
builds. But the cost of invoking the wrapper script can be significant;
it's an extra process or two to launch for every single compilation.
Instead, let's have clang-cl generate the dependencies directly, which
should be somewhat faster.
That NDK bug has been fixed since r8c, and we now require something more
recent than that. This effectively reverts the changes from bug 720621
and bug 734832.
--HG--
extra : rebase_source : 9ff76a790ec4135dc0172cfd0f11fc1ecef7df64
The moz.build Java JAR definitions are, of course, broken, but they
will be removed soon enough.
MozReview-Commit-ID: KIxqLDwd9I7
--HG--
extra : rebase_source : 8312b3f125793f73d3e835d1c0a5c7cabd4ebc0c
CFBundleIdentifiers can only contain [A-Za-z.-], and by convention
the app component is lowercase and does not contain '.'.
Make configure delete all characters other than [a-z-] when generating
MOZ_MACBUNDLE_ID from MOZ_APP_DISPLAYNAME.
--HG--
extra : rebase_source : f80df747c0c0ed6dae1cd9f2dc0e916da911cf8b
This is ancient and the team that used it (gfx) is no longer using it.
MozReview-Commit-ID: HrDgmAU9QeW
--HG--
extra : rebase_source : c4a64965c4ae1a50888893e881a6e8a9688a58b6
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 22008e9333b15c594ce26c2a52f67396d6e3ab84
extra : source : f918500d9cf5112b70bc8e0a120df435b02252b7
It hasn't been used for a long while, and the screenshot tool is only
used for tests. So keeping the code essentially always disabled doesn't
have much value.
--HG--
extra : rebase_source : 6bf696d6543cbdd3ef66e19d4dc110134b761b63
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : 5547e2c8fbf4e2e87182b8720d8352c131e4ec65
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 38a9781c472d858f3300cbbcbdc6d2311c465713
After landing bug 1356263, no one uses HAVE_I18N_LC_MESSAGES. So it is
unnecessary to check LC_MESSAGES.
MozReview-Commit-ID: IPgl3rQ2qrd
--HG--
extra : rebase_source : 542ada2cf9ac2775855bba29f39044b55fa93f20
New Android-Gradle plugins pin the build-tools version, and we want to
be consistent between Gradle and moz.build.
MozReview-Commit-ID: ApWS4rHzPuH
--HG--
extra : rebase_source : 5a5730b4b9ce84af40a7c73c4f1abba017103f02
The OSX linker apparently decides on its own to link against system
frameworks. We end up with libxul linked to 6 frameworks that were never
given on the command line, and we do use symbols from those.
Interestingly, for those frameworks that don't appear on the command
line, there is no determinism in how stubs for lazy bindings (equivalent
to Linux's PLT, AIUI) are laid out in the binary. But for those that do
appear on the command line, the layout is deterministic.
So add those frameworks to the command line.
With this change, the remaining difference between two builds of the
same changeset on try is due to symbol tables for profiling. Stripping
those (like we do on beta/release) produces no differences.
--HG--
extra : rebase_source : 151342f3c0067c16c26e111247f6da58f4b639be
At the same time, we make it actually do something on spidermonkey
builds. We also add an environment variable alternative, that we use
in mozconfig.stdcxx, allowing for mozconfig.no-compile to override it
and avoid configure failures on e.g. artifact builds.
--HG--
extra : rebase_source : b68d362025e0c99f9184a03391c652ec2c9357ad
Bug 1325632 added some facility to add target compiler flags. This
change extends it to add allow adding host compiler flags as well.
--HG--
extra : rebase_source : 424b405a1d8f9a4778ff75c3308c9622f050e194
