This includes several fixes required to build against musl libc.
Conflicts were resolved in 00-arm-exidx-rollup.patch and
10-json-upload.patch. 08-dont-add-sp-to-clobber-list.patch was
applied upstream and is no longer needed. The others applied cleanly.
breakpad_getcontext.S is now built conditionally based upon the
available of getcontext() from libc, rather than only on Android.
The profiler was updated to reflect this change.
Differential Revision: https://phabricator.services.mozilla.com/D67108
--HG--
rename : toolkit/crashreporter/breakpad-patches/09-gnu-alt-form-minimal-support.patch => toolkit/crashreporter/breakpad-patches/08-gnu-alt-form-minimal-support.patch
rename : toolkit/crashreporter/breakpad-patches/10-json-upload.patch => toolkit/crashreporter/breakpad-patches/09-json-upload.patch
rename : toolkit/crashreporter/google-breakpad/src/common/android/breakpad_getcontext.S => toolkit/crashreporter/google-breakpad/src/common/linux/breakpad_getcontext.S
rename : toolkit/crashreporter/google-breakpad/src/common/android/breakpad_getcontext_unittest.cc => toolkit/crashreporter/google-breakpad/src/common/linux/breakpad_getcontext_unittest.cc
extra : moz-landing-system : lando
CLOSED TREE
Backed out changeset 85ea1d36da66 (bug 1515451)
Backed out changeset 779bc1fa07ae (bug 1515451)
Backed out changeset 0c6771b60b76 (bug 1515451)
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--HG--
extra : moz-landing-system : lando
clang-cl versions older than 8 are already rejected in
toolchain.configure as of bug 1550868.
Differential Revision: https://phabricator.services.mozilla.com/D64261
--HG--
extra : moz-landing-system : lando
These vary per-target, and it's nicer to define them here rather than
define them somewhere in rules.mk.
Depends on D62796
Differential Revision: https://phabricator.services.mozilla.com/D62797
--HG--
extra : moz-landing-system : lando
We're going to need this for handling Mac cross compiles correctly.
Depends on D62795
Differential Revision: https://phabricator.services.mozilla.com/D62796
--HG--
extra : moz-landing-system : lando
Legacy extensions are no longer loaded, so we can drop the build config for it. We
still need flags for handling experimental APIs since what we require differs between builds
and distributions.
Differential Revision: https://phabricator.services.mozilla.com/D57413
--HG--
extra : moz-landing-system : lando
...so that we can correctly declare that we are using sandboxed
library(ies) from our "parent" build, but not check for all the tools to
compile code.
Depends on D59554
Differential Revision: https://phabricator.services.mozilla.com/D59555
--HG--
extra : moz-landing-system : lando
This change eliminates a lot of repetition, and paves the way for the
next change.
Differential Revision: https://phabricator.services.mozilla.com/D59554
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
The remote agent used to not compile on Windows AArch64 due to iovec's
dependency on a version of winapi without support for this architecture.
Now that the remote agent has upgraded to http 0.2, which depends on
a version of the bytes crate that has moved away from iovec in favour
of std::io::IoSlice, we are able to turn on support for Windows AArch64.
This in turn will also fix bug 1606935 because the browser-chrome
test manifest for M(remote) will no longer be empty. It was a
regression caused by 1603930 where we fixed a logic error causnig
ENABLE_REMOTE_AGENT to be inappropriately set on non-trunk branches.
Differential Revision: https://phabricator.services.mozilla.com/D58767
--HG--
extra : moz-landing-system : lando
The remote agent component was meant to only be built on the
Nightly release channel, but 868b1bf043dc accidentally reversed
--enable-cdp and --reverse-cdp, not understanding that there's a
semantic difference in the build config parser for this.
This has had the undesired effect that the remote agent has been
built on all release channels since around 25th April of this year.
This in itself is not a huge concern because the feature is disabled
through the remote.enabled preference in modules/libpref/init/all.js,
except on Nightly.
This patch reverses s/disable/enable/ which causes ENABLE_REMOTE_AGENT
to be set only on the Nightly release channel, or when --enable-cdp
is explicitly used, thus achieving the original, intended effect.
We caught this when running the bc test
remote/test/browser/browser_agent.js as part of beta simulations
for Firefox 73. I wrote that test explicitly to test for this
eventuality, so I will consider it good enough for this change to
ship without additional tests.
Differential Revision: https://phabricator.services.mozilla.com/D58452
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
This patch is not ideal: if would be better to do the defaulting in
`toolkit/moz.configure`, but doing it there runs into problems with base
toolchain configurations, as the clang there is not new enough. So we
have this, doing everything with environment variables, which is easily
turned on or off, depending on the needs of the specific configuration.
The `mozconfig.no-compile` change is not really needed, as the wasm
sandboxing detection bits are not conditional on
`--enable-compile-environment`. Those bits should be, and I will tackle
doing that after the holidays.
Differential Revision: https://phabricator.services.mozilla.com/D58102
--HG--
extra : moz-landing-system : lando
We often include common mozconfig fragments to turn various options on.
When doing that, environment variables are more easily turned off by
later mozconfig fragments (e.g. `build/mozconfig.no-compile` for
artifact builds) than command-line options. Therefore, include an
alternate environment variable for identifying the location of the wasi
sysroot.
Differential Revision: https://phabricator.services.mozilla.com/D58037
--HG--
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
This change modifies all tests that use key3/cert8 to use the new files. It
removes test_sdr_upgraded_with_password, as without the upgrade part that is now
the same test as test_sdr_preexisting_with_password.
Differential Revision: https://phabricator.services.mozilla.com/D55708
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key4.db => security/manager/ssl/tests/unit/test_broken_fips/key4.db
extra : moz-landing-system : lando
