We've landed some recent changes that implicitly require SDK
10.0.17134.0. Since we've been building with that version for some time
in automation, let's go ahead and raise the minimum version accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D28671
--HG--
extra : moz-landing-system : lando
We moved fuzzing options out of `toolkit/moz.configure` into `js`'s
configure a while back, but we seem to have snuck some fuzzing-related
options into `toolchain.configure` in the interim. But we can't make
the `toolchain.configure` bits depend on the `js` bits; let's just put
everything in `toolchain.configure`.
Differential Revision: https://phabricator.services.mozilla.com/D28084
--HG--
extra : moz-landing-system : lando
We were never adjusting `last` in this loop, so we were computing the
wrong addresses for all sections beyond the first. Which in turn meant
that we would compute the wrong size for the section data we needed to
allocate.
Differential Revision: https://phabricator.services.mozilla.com/D28195
--HG--
extra : moz-landing-system : lando
It seems better to set switches enabling runtime libraries and switches
enabling runtime libraries to build in different places, as future
changes might only enable runtime libraries for certain targets, but not
need any special switches for building.
Depends on D27594
Differential Revision: https://phabricator.services.mozilla.com/D27595
--HG--
extra : moz-landing-system : lando
`android_targets` here is a dict, not a sequence, and while `iter` on a
dict object implicitly means `dict.iterkeys()`, that's not really
obvious. We should instead be explicit about what we're doing here.
Depends on D27593
Differential Revision: https://phabricator.services.mozilla.com/D27594
--HG--
extra : moz-landing-system : lando
We don't need them and we might as well be explicit about not building them.
Depends on D27592
Differential Revision: https://phabricator.services.mozilla.com/D27593
--HG--
extra : moz-landing-system : lando
The setup for compiler-rt is currently done before the stage 2 build,
which happens to be the final stage for our android runtime libraries
build. But we may also want to build runtime libraries on 3-stage
bootstrap builds, in which case we don't want compiler-rt to be active
for the second stage. Move the setup into build_one_stage so that the
setup is controllable by is_final_stage, which is set in all the place
that we care about.
Differential Revision: https://phabricator.services.mozilla.com/D27592
--HG--
extra : moz-landing-system : lando
Before this patch, we first find an executable, then check the version. So if
the first executable we find is outdated, we won't look for others.
Instead, check each of them for different versions manually. This will also
unblock bug 1540533, since at that point we know that we'll be able to find
a cbindgen with the right version.
Differential Revision: https://phabricator.services.mozilla.com/D27890
--HG--
extra : moz-landing-system : lando
We were allocating ElfSection's data with `new[]` and modifying it with
`realloc` in some places, which causes allocator mismatches.
Consistently manage the data with `malloc`, `realloc`, and `free` instead.
Differential Revision: https://phabricator.services.mozilla.com/D27327
--HG--
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
Bug 1500504 added a version check for the SDK, but it only does the
check if --with-macos-sdk is used. We should also check the version when
using the default SDK.
Note that this means we now set MACOS_SDK_DIR to be the default SDK even
if it wasn't set explicitly from --with-macos-sdk
Differential Revision: https://phabricator.services.mozilla.com/D17727
--HG--
extra : moz-landing-system : lando
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
If mozbuild parsing fails due to a missing file (eg: a file not existing
in UNIFIED_SOURCES), then no Makefiles are written out, but
config.status exists. This would cause mozbuild to think that configure
doesn't need to run, and rely on make to perform the backend-out-of-date
check in rebuild-backend.mk. Unfortunately since no Makefiles were
written, the make command fails immediately and no attempt is made to
re-create the backend. Note that this is only a problem if the first
mozbuild parsing from a clobber build fails, otherwise there is
typically a top-level Makefile from a previous build to call into (at
which point make can determine it is out-of-date, and re-invoke itself).
The fix is to have the RecursiveMake backend re-use the same logic that
was introduced into mozbuild for alternate backends, and remove
rebuild-backend.mk. This way, mozbuild can always determine if the
backend needs to be regenerated, even if the initial parsing failed.
Test code was also relying on rebuild-backend.mk to generate the
TestBackend, but moving backend_out_of_date() into MozbuildObject allows
this code to be shared.
Differential Revision: https://phabricator.services.mozilla.com/D26262
--HG--
rename : build/gen_test_backend.py => python/mozbuild/mozbuild/gen_test_backend.py
extra : moz-landing-system : lando
This imports the changes from wheezy-lts (http://deb.freexian.com/extended-lts/)
and creates a package we install in the debian7-based images (with a
modified version number to work around bug #1419577.
This leaves out debian7-raw and debian7-packages as unpatched, because
of the chicken-and-egg problem.
Depends on D26100
Differential Revision: https://phabricator.services.mozilla.com/D26102
--HG--
extra : moz-landing-system : lando
When cross-building with clang, we use `--target` with a target that is
derived from the configure target, with the vendor removed. So for
`configure --target=aarch64-unknown-linux-gnu`, we use
`clang --target=aarch64-linux-gnu`.
Then, clang itself looks for tools as `$target-$tool` first, then
`$tool`, which means for the assembler, it's looking for
`aarch64-linux-gnu-as` before `as`, but not
`aarch64-unknown-linux-gnu-as`.
Building GNU as with `--target=aarch64-unknown-linux-gnu` creates the
`aarch64-unknown-linux-gnu-as`, but we really want `aarch64-linux-gnu`,
so we adjust the target in the binutils build script.
Differential Revision: https://phabricator.services.mozilla.com/D25684
--HG--
extra : moz-landing-system : lando
As of clang 8, llvm-config doesn't return all flags clang was built
with, and omits some flags that do impact the libclang ABI,
-stdlib=libc++ being one of them (it might well be the only one).
Building clang with LLVM_ENABLE_LIBCXX=ON does build it with
-stdlib=libc++, but is unrelated to whether or not libc++ is built and
shipped with clang, which still happens without it.
So while versions older than clang 8 are not really affected, it doesn't
hurt to build clang without -stdlib=libc++ (especially when it
currently only applies to the clang used to cross build android with
PGO, not even the other android cross builds), in preparation for
switching to clang 8.
Differential Revision: https://phabricator.services.mozilla.com/D25031
--HG--
extra : moz-landing-system : lando
There is no concern that the Android NDK clang may not support it, as
the flag was added in clang 2.9. The flag is also not supported with
GCC, which is not ideal, but we already crossed that bridge at least
with -gcc-toolchain added in extra_toolchain_flags, which is not
supported by GCC either.
Differential Revision: https://phabricator.services.mozilla.com/D25019
--HG--
extra : moz-landing-system : lando
We shouldn't pass those flags when building C. It doesn't matter /too/
much currently, but will in a subsequent change, which will introduce
a C++-only flag in stlport_cppflags.
Differential Revision: https://phabricator.services.mozilla.com/D25018
--HG--
extra : moz-landing-system : lando
Other than the MediaPipelineFactory references, nothing else is obsolete, so this is a
very minor cleanup, just to improve readability a bit.
Differential Revision: https://phabricator.services.mozilla.com/D25124
--HG--
extra : moz-landing-system : lando
Last time we updated the requirements was in bug 1278456, after we
switched to GTK+3.
While it might be worth checking what would be a reasonable requirement,
the immediate problem is that updating ANGLE hits a snag with a
libstdc++ 4.7 symbol, and the only main distro release that bumping to
that version would make us not support anymore is Ubuntu 12.04 LTS,
EOLed 2 years ago (April 2017).
Bumping to some even newer version would need more consideration.
Desupporting Ubuntu 12.04 LTS at this point is almost a no-brainer.
Differential Revision: https://phabricator.services.mozilla.com/D23979
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
When installing JDK 1.8, it writes path to the following registry.
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.8\JavaHome
So we use this registry to detect JDK installation path on Windows if available.
Differential Revision: https://phabricator.services.mozilla.com/D20449
--HG--
extra : rebase_source : d8a380d9839f4de749815f3c81665e8d00226862
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
The current setup uses different ways for different platforms, with
different workarounds, even using extra configuration items for Windows.
Now that there can't be a difference between the host per the build
system and the host per rust, we can get rid of those configuration
items, and use a more common infrastructure.
We cannot, however, avoid using wrapper scripts, because per-target rust
link-arg flags don't work up great.
The downside is that multiplies the number of wrappers, as we now have
to have a different one for host and target, and then we have .bat files
and shell scripts for, respectively, Windows hosts, and other hosts.
Depends on D24321
Differential Revision: https://phabricator.services.mozilla.com/D24322
--HG--
extra : moz-landing-system : lando
While the substitution pattern is kind of awful in make, it will allow
to more straightforwardly deal with the difference between target and
host.
Differential Revision: https://phabricator.services.mozilla.com/D24321
--HG--
extra : moz-landing-system : lando
Newer versions of rust come with a specialized arm target that matches
more closely our armv7 targets (with neon and thumb2), so use that when
possible.
Depends on D24324
Differential Revision: https://phabricator.services.mozilla.com/D24325
--HG--
extra : moz-landing-system : lando
Some of our builds use --enable-warnings-as-errors and some don't, and I can't
figure out a way to write an expectation comment for that.
Differential Revision: https://phabricator.services.mozilla.com/D24469
--HG--
extra : moz-landing-system : lando
MT is part of the Windows SDK, not MSVC, but an alternative exists for
it: llvm-mt. The official LLVM distribution for Windows doesn't include
it[1], though, so we can't just switch to it.
1. https://bugs.llvm.org/show_bug.cgi?id=40152
While here, remove the .exe suffix from the check, to future-proof for
cross-windows builds.
Differential Revision: https://phabricator.services.mozilla.com/D24326
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
We need to have full symbols uploaded for the upcoming EME-enabled
win64-aarch64 nightlies, and the tasks to do that are derived from the
nightly itself, which is going to be an artifact build. Bug 1527463 took
care of adding the option to enable that, and we turn it on for
EME-enabled builds.
MOZ_ARTIFACT_TASK_WIN32_OPT is not exactly the right thing, but we're
already using it to enable EME in
browser/config/mozconfigs/win64-aarch64/common-opt and is only set on
those builds.
Differential Revision: https://phabricator.services.mozilla.com/D23639
Since these are compile-time constants, they can't exactly go away on us due to
running script, right?
Differential Revision: https://phabricator.services.mozilla.com/D24195
--HG--
extra : moz-landing-system : lando
We need to typecheck the trivials too, not just the final thing after trivials
are stripped, because casts are trivials.
Differential Revision: https://phabricator.services.mozilla.com/D24186
--HG--
extra : moz-landing-system : lando
The old code for member method calls did the following:
1) Find the member method calls.
2) Look at their "this" expression.
3) If the "this" is an operator call, check for any of the arguments of the
operator call being invalid.
4) Otherwise (if not an operator call) check for the "this" value being
invalid.
This wasn't right, because the "is invalid" check checks the type and only
considers refcounted things. So if the code looked something like
"foo[i]->call_method()", we would look at the types of "foo" and "i" and
determine that none of those are refcounted types so there is nothing invalid
here (since "foo" is some sort of array type and "i" is an integer). The new
setup just checks whether the "this" value is invalid, which does the type
check on the "this" value itself; in the "foo[i]->call_method()" case on
"foo[i]". We then adjust the exclusions in InvalidArg to consider operator->
on known-live things valid, to allow the thing that we were really trying to
accomplish with the "check for an operator call" bits:
"stackRefPtr->some_method()".
The test coverage being added for the made-up TArray type is meant to catch
things like the geolocation issue that was being hidden by the buggy behavior.
I'm not using nsTArray itself because some header included by nsTArray.h
tries to define operator new/delete bits inline and that triggers warnings that
then cause a clang-plugin test failure, because they're unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D24117
--HG--
extra : moz-landing-system : lando
"this" is guaranteed to stay alive as long as other MOZ_CAN_RUN_SCRIPT
conditions hold, and its const members can't change value and drop
their refs.
Differential Revision: https://phabricator.services.mozilla.com/D23997
--HG--
extra : moz-landing-system : lando
This allows calling a C++ MOZ_CAN_RUN_SCRIPT method that takes a callback argument.
The changes to TestCanRunScript.cpp are there to catch an incorrect change I was
going to make to the analysis to make this work, until I figured out that
RootedCallback should be MOZ_IS_SMARTPTR_TO_REFCOUNTED.
Differential Revision: https://phabricator.services.mozilla.com/D23519
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
The file is essentially limited to ARM flag tweaks, so we make the
corresponding python configure code ARM-only. In large parts, the
python code sets things up similarly, although in a few places we try to
be smarter about than the current autoconf-based code.
The resulting config.status have been verified to only have
insignificant differences on both arm and aarch64 android builds.
Depends on D24000
Differential Revision: https://phabricator.services.mozilla.com/D24001
--HG--
extra : moz-landing-system : lando
See https://bugs.llvm.org/show_bug.cgi?id=38944. clang thought it could safely leave out type information for some of our classes, but that information would have been helpful for debugging. The flag in this patch turns off the debug-info limiting.
Differential Revision: https://phabricator.services.mozilla.com/D24073
--HG--
extra : moz-landing-system : lando
Without this flag, Android PGO profile-use builds may fail with
"Function control flow change detected" errors.
Differential Revision: https://phabricator.services.mozilla.com/D22816
--HG--
extra : source : 3dfc0e4f8e7c8cd48b911033222fb3c3edb9762b
In at least some libstdc++ versions, std::pair (which we want to be
memmovable) inherits from __pair_base. We have a similar setup
already for __atomic_base.
Differential Revision: https://phabricator.services.mozilla.com/D23698
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
Updating clang indicates that 32-bit compilation is substantially longer
than 64-bit compilation, perhaps due to swapping. The compilation
process is hitting the timeout limit shortly before the compilation
process completes (~3681/3695 tasks according to ninja).
We could tweak our clang build process to accommodate this job. But we
don't support building on 32-bit Windows anymore, and we don't produce a
32-bit Windows clang either. So we shouldn't support a 32-bit Windows
clang-tidy job either. Let's get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D23517
--HG--
extra : moz-landing-system : lando
We do this to encourage clang to find an new-enough linker instead of
the system one.
Differential Revision: https://phabricator.services.mozilla.com/D22881
--HG--
extra : moz-landing-system : lando
We want our clang bootstrap to use the GCC headers we're building with,
not whatever sysroot it happens to find on the server we're building on.
The -gcc-toolchain argument we specify when building clang will also be
picked up by llvm-config, so we need to strip it out when building the
plugin. Otherwise, we will get peculiar failures about not being able to
find C++ header files.
Depends on D22879
Differential Revision: https://phabricator.services.mozilla.com/D22880
--HG--
extra : moz-landing-system : lando
Explicit is better than implicit, and helps ensure that GCC is always
using the binutils we built it with, rather than the system binutils.
Differential Revision: https://phabricator.services.mozilla.com/D22879
--HG--
extra : moz-landing-system : lando
The only place we'd need the compat libraries would be for host
binaries, and those shouldn't be a problem given that our system images
are new enough.
Differential Revision: https://phabricator.services.mozilla.com/D22873
--HG--
extra : moz-landing-system : lando
A newer clang may require newer binutils than the system provides, so we
should ensure that we provide just such a binutils.
Differential Revision: https://phabricator.services.mozilla.com/D23393
--HG--
extra : moz-landing-system : lando
These toolchain tasks are the last ones using the historical
download-tools script from build/unix/build-gcc, which invokes gpg to
validate the downloaded tarballs. The consequence is that gpg-agent is
spawned and stays running, preventing a cleanup script from doing its
job, making the tasks fail.
Fetches are the new way to download sources, and can also do gpg
validation without those caveats.
The download-tools.sh script can then be removed as it's not used
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D22682
--HG--
extra : moz-landing-system : lando
This way if a caller calls a method that has a MOZ_CAN_RUN_SCRIPT override, it
can detect that it's possibly calling a MOZ_CAN_RUN_SCRIPT thing without having
to know about the override.
Differential Revision: https://phabricator.services.mozilla.com/D22839
--HG--
extra : moz-landing-system : lando
Cosmin Sabou
Nathan Froyd
Gabriele Svelto
Ehsan Akhgari
Jesse Schwartzentruber
Emilio Cobos Álvarez
Eric Rahm
Chris Manchester
Mike Shal
Mike Hommey
Oana Pop Rus
Mike Shal
Daniel Varga
Csoregi Natalia
Bobby Holley
Tom Prince
Andreea Pavel
Masatoshi Kimura
Christian Holler
Noemi Erli
Sylvestre Ledru
Andi-Bogdan Postelnicu
Nick Alexander
Ciure Andrei
Geoff Brown
Thomas Daede
Boris Zbarsky
Gurzau Raul
David Major
Coroiu Cristina
Makoto Kato
Nicholas Nethercote
shindli
Brindusan Cristian
Wes Kocher
Gian-Carlo Pascutto
Nathan Froyd
Carolina Jimenez Gomez