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
--enable-ion was only used by --enable-simulator and related options, so
there wasn't much point in making two separate commits.
This translation is a little more verbose than the original
old-configure code, but I think it is more readable and easier to
follow. We also don't port over --enable-simulator=no, as there doesn't
seem to be much point in doing so.
This is an import of the change from https://github.com/mozsearch/mozsearch/pull/66
plus a correction in the README file. The change was reviewed in github.
MozReview-Commit-ID: A7gINlBubZ4
And statically link logalloc.
Statically linking is the default, except when building with
--enable-project=memory, allowing to use the generated libraries from
such builds with Firefox.
--HG--
extra : rebase_source : efe9edce8db6a6264703e0105c2192edc5ca8415
Cosmin Sabou
Nathan Froyd
Mike Hommey
Tom Prince
Dorel Luca
Ted Mielczarek
Ralph Giles
Sylvestre Ledru
Tom Ritter
David Major
Nick Alexander
shindli
Bogdan Tara
Julian Hector
Tim Taubert
Ryan VanderMeulen
Gurzau Raul
Andrew Halberstadt
David Keeler
Marco Castelluccio
Noemi Erli
Ciure Andrei
Edouard Oger
Kartikaya Gupta