Sprinter::jsprintf is nowadays the same as GenericPrinter::printf which Sprinter
inherit from. This patch removes all calls to Sprinter::jsprintf and replaces
them by Sprinter::printf.
The advantage of using GenericPrinter::printf is that this reduce the dependency
on Sprinter-specific interface and moves us toward being able to move more
consumers over to the GenericPrinter.
Differential Revision: https://phabricator.services.mozilla.com/D181500
Targeting aarch64 for Android builds on aarch64 hosts to ensure that we build an arm64 artifact that will run on an arm64 emulator, which is the only one that is supported.
Differential Revision: https://phabricator.services.mozilla.com/D187075
Targeting aarch64 for Android builds on aarch64 hosts to ensure that we build an arm64 artifact that will run on an arm64 emulator, which is the only one that is supported.
Differential Revision: https://phabricator.services.mozilla.com/D187075
Because it bumps the alignment requirement on aarch64, we make the
elfhack test create more relocations to make the .rela.dyn section large
enough for the test to pass.
Differential Revision: https://phabricator.services.mozilla.com/D181684
Clang trunk started to warn about uses of snprintf that always lead to
truncation. The warning is hit in the test, but it's not really an
interesting part of the test, so prevent clang from warning by making
the format string smaller.
Differential Revision: https://phabricator.services.mozilla.com/D186990
It has been enabled by default on the relevant platforms essentially
forever, so it doesn't need to be explicitly enabled.
As such, since --enable-crashreporter is not really a useful thing to
point at to wrt build options, we remove its mention from the
configuring build options doc.
Differential Revision: https://phabricator.services.mozilla.com/D186513
We've apparently hit a threshold in non-unified builds where there are
too many files on the command line when creating the js_static library
on Windows. The way around that is to do something similar to shared
library linking, using a response file (shared library linking has more
possibilities, but it's a different story). Unfortunately, not all
static library creation tools are equal, and while llvm-lib, GNU ar and
llvm-ar support response files, BSD ar and probably others (e.g. the one
on Solaris?) don't, so we have to try and detect whether that works.
Differential Revision: https://phabricator.services.mozilla.com/D185419
Some third party code (cairo, pixman, some media libs) rely on this
define being set. When they are built standalone, they get it from
autoconf, but we don't run their configure scripts, so that's missed.
Differential Revision: https://phabricator.services.mozilla.com/D185351
In bug 1839743, we made the build system prefer packed relative
relocations to elfhack when both the system libc and linker support
them. Unfortunately, while that covers most of the benefits from
elfhack, it doesn't cover bug 651892.
To cover it, we make every C++ executable contain its own copy of
the symbol, so that all relocations related to it become relative.
And because this is actually (slightly) beneficial on macos, and because
it's also an advantage to have our own abort called rather than the
system's, we apply the same to all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D184068
This changes the minimum macOS target from 10.12 to 10.15 in several build
scripts and in documentation that references the minimum version
requirement.
Differential Revision: https://phabricator.services.mozilla.com/D184432
Since it depends on the `command_handlers` from `Registrar` for the
`file` `sub_command` to determine the appropriate component, we need to
load all command modules so that we can file against any of them.
Differential Revision: https://phabricator.services.mozilla.com/D184853
This just forces other command modules to be loaded in addition to the
'base' command. We need this so that decorators needed by the 'base'
command that are in another command module are ran during initialization
(eg: `@SettingsProvider`).
I thought about centralizing the `@SettingsProvider` decorators into one
module and always loading it, but they can depend on the
'command_handlers' in `Registrar`, so the modules they're currently in
have to be loaded for them to execute, so there wasn't a way around
this.
Differential Revision: https://phabricator.services.mozilla.com/D184852
