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
We currently use a 32-bit Rust toolchain for win32 builds, but this can lead
to OOM situations. This patch makes win32 builds use a 64-bit Rust toolchain,
which requires a little bit of extra configuration because rustc needs to
be able to find a link.exe that produces 64-bit binaries for building
things like build scripts, which are host binaries.
We will now generate a batch file that sets LIB to the paths to 64-bit
libraries and invokes the x64-targeting link.exe, and add a section to the
.cargo/config file to instruct cargo to use that batch file as the linker
when producing 64-bit binaries.
MozReview-Commit-ID: 9vKBbm7Gvra
--HG--
extra : rebase_source : 366dd966cafe4f07b8e59fc170d2db2dada32627
Both the cc crate and the rust compiler may want to use "cc", which,
on automation, points to the system GCC compiler instead of ours.
As a workaround, we add a cc symbolic link in the GCC toolchain artifact
so that, as long as the GCC toolchain artifact's bin directory is in
$PATH early enough, it's picked over /usr/bin/cc.
--HG--
extra : rebase_source : 53cacf8a750539706a484218e168c8c9e0ba49a6
The "contract" for toolchains is that extracting foo.tar.xz creates a
directory named foo/. That is however not true for mingw32.tar.xz, which
extracts into gcc/, possibly overwriting files from the gcc.tar.xz
archive (which is also used for mingw builds, for the host part).
This is also not true for nsis.tar.xz, but it reportedly has problems
when it's not in the same directory as mingw32.
But mingw32 doesn't actually need to be mixed with gcc, so it's better
to separate them as they are supposed to be.
--HG--
extra : rebase_source : 30d90af64459bbb31bc076e48f3c661fa9cd4a79
We need MOZ_UI_LOCALE even when building the JS shell so
config/config.mk variable assignments don't run into issues. But it
doesn't make any sense to configure a UI locale for the JS shell. So
make --enable-ui-locale a normal `option`, but give it a `default`,
which is the value shell-only builds will always see.
--HG--
extra : amend_source : 047759dd6ec446d9d6f8f5992ed9cf6628ce859e
This has the virtue of not executing python three times during configure
just to read the same value of milestone.txt and munge it. We can also
remove milestone.py as a happy side effect, so all the milestone
computations can be done in init.configure.
lld is being too smart for its own good, and places non-relocatable data
right after the program headers, which prevents the program headers from
growing. But elfhack wasn't checking for that, so happily placed the
non-relocatable data at its non-relocated location, overwriting the last
item of the program headers.
--HG--
extra : rebase_source : 6f26d475f0a19d88ddf21399dbce8ceac62b492d
Bug 1385783 changed things such that the two elfhack sections are not
adjacent anymore. They can even be in different segments in some cases,
but the undo code doesn't know how to actually handle that case.
So for now, allow non adjacent sections, but still verify that they are
in the same segment.
--HG--
extra : rebase_source : da95ef7df19eeea8dfd07b24f22e7bee18939b69
Bug 1423803 was attempting to remove the fallible library but didn't do
so on Android because of this bug. We can now fully retire it.
--HG--
extra : rebase_source : de38872a08d24768eadfbe81652cfcd6aa7aa041
Bug 1256642 introduced magic at the emitter level to determine whether a
binary contains C++ sources and should be linked with the C compiler or
the C++ compiler.
Unfortunately, the Binary() moz.build template always adds C++ OS
libraries on Android (through STLPORT_LIBS), and C++ libraries on Linux
(stdc++compat).
The latter only ends up forcing every Binary() to be linked with the C++
linker, which is unfortunate, but doesn't cause much problems. The
former, however, involving OS libraries, the magic from bug 1256642
doesn't kick in, so we end up trying to link C++ OS libraries with the C
linker. Which ends up failing, because the libraries in STLPORT_LIBS
require -lm, which, while it's added by the C++ compiler when linking,
is not when the linkage is driven by the C compiler.
Because the fallible library, linked to all GeckoBinary()s is a C++
library, we still ended up linking with the C++ compiler on Android, so
this wasn't actually causing any problem... until I tried to remove that
fallible library in bug 1423803.
Anyways, the core problem is that moz.build evaluation is happening too
early to know whether any C++ sources are being linked together, so
there is no way the Binary() template can do the right thing. So this
change moves the logic to the emitter.
This also changes the type of STLPORT_LIBS to a list.
--HG--
extra : rebase_source : a70ddf7a132f94dc10e7e1db94ae80fb8d7a269f
upload-generated-sources tasks simply use `mach python` to run an in-tree
script, so they can save time by using a sparse profile.
MozReview-Commit-ID: LbXlibOP34W
--HG--
extra : rebase_source : c6b580b15671edeb700d191f651c79c6d6423394
Bump the minimum required Rust version now that 1.22.1
has been in stable release for more than two weeks.
Version 1.22.0 works fine everywhere but macOS 10.13,
but 1.22.1 was released the same day, so it's no harder
to upgrade to.
Also update the base-toolchain builds to ensure we
continue to build with this version.
MozReview-Commit-ID: GlRWUNE07G0
--HG--
extra : rebase_source : f37585db5633e6e64b02bc94c2516b5ab18c3e15
With all of our builds in Taskcluster now, we should never be uploading
symbols from build tasks. Unfortunately Windows builds were still doing so.
This patch removes MOZ_AUTOMATION_UPLOAD_SYMBOLS from all the in-tree
mozconfigs and a few other places so that it should always default off
(per moz-automation.mk). The rest of the uploadsymbols bits will be
removed once Thunderbird fixes their automation.
This patch was mostly autogenerated by running:
rg --files-with-matches UPLOAD_SYMBOLS browser/config/mozconfigs/ mobile/android/config/mozconfigs/ | xargs sed -ri '/.*UPLOAD_SYMBOLS.*/d'
sed -ri '/.*UPLOAD_SYMBOLS.*/d' build/unix/mozconfig.linux build/mozconfig.win-common build/macosx/local-mozconfig.common build/mozconfig.automation
Then mobile/android/config/mozconfigs/common and
taskcluster/scripts/builder/build-linux.sh were hand-edited.
MozReview-Commit-ID: Cy8kSEodSg4
--HG--
extra : rebase_source : 01caf1651b4eb428313e1f371aa585f8f34c4151
The upload-symbols task simply runs an in-tree Python script with
`mach python` so using a sparse profile will make this a bit faster.
MozReview-Commit-ID: 5HzwMf1FZLU
--HG--
extra : rebase_source : 74046b7917ee2e2ea7be0ec24f777f5fe819ef58
Will also address Bug 1377553 and part of Bug 1419607
MozReview-Commit-ID: AUCqBxEGpAl
--HG--
extra : rebase_source : f7582d7089f0f4582a02aeaef090dc0701df994d
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : a3f0a76b1ae6b3cd952271782f9d0c2463b704e0
With Gradle integration centralized in gradle.configure, changing
these integration points will need to trigger the android-* tasks.
MozReview-Commit-ID: DuOuW1RIgCh
--HG--
extra : rebase_source : 9aecfab8a8ce41441fb4c25021b14263d9c115c2
The std::nothrow variant of operator new is effectively a fallible
operator new. It is used in third party code.
The duplication with our own fallible operator new is unfortunate, and
we can reduce it by making one an alias of the other.
We keep the fallible library as a dummy on Android because bug 1423802
induces some linking problems.
--HG--
extra : rebase_source : d7b915aaafde40057e87b7ad4bbd82d348e4f12d
The last use in gecko was removed in the previous change, and the only
use in comm-central should be trivial to remove. It's not worth the
extra complexity to keep this argument.
--HG--
extra : rebase_source : 8576316190bf58476b7eb262deae4c972ea3dc2f
This is a new module that will provide a place to store some common
abstractions around the 'blessings' module. The main entrypoint is:
from mozterm import Terminal
term = Terminal()
If blessings is available, this will return a blessings.Terminal()
object. If it isn't available, or something went wrong on import,
this will return a NullTerminal() object, which is a drop-in
replacement that does no formatting.
MozReview-Commit-ID: 6c63svm4tM5
--HG--
extra : rebase_source : 9ab221774d92a418d9b098d79bb2c88f75d937f8
This library will be used to create test COSE signatures for the new COSE add-on
signature verification implementation.
MozReview-Commit-ID: KshKHwusT5h
--HG--
extra : rebase_source : 22d65622a77afc93b756829c8ffb4f37101dad26
extra : histedit_source : 869b9b65bdf201a027914a8127d28e5e9baf4d33
Mike Hommey
Csoregi Natalia
Ted Mielczarek
David Major
Ryan VanderMeulen
Nathan Froyd
Nathan Froyd
Aki Sasaki
Cosmin Sabou
Tom Prince
Dorel Luca
Ralph Giles
Sylvestre Ledru
Tom Ritter
Nick Alexander
shindli
Bogdan Tara
Julian Hector
Tim Taubert
Gurzau Raul
Andrew Halberstadt
David Keeler