This is some sort of followup to bug 1423813, providing a minimalistic
way to undo elfhack when the elfhack sections are in separate segments,
which has been the case since bug 1385783 but didn't cause problems
on Android builds until bug 1423822.
Depends on D9622
Differential Revision: https://phabricator.services.mozilla.com/D9623
--HG--
extra : moz-landing-system : lando
This effectively backs out bug 822584, which worked around a similar
problem to what we are facing with Android xpcshell, being that the
crash reporter doesn't handle the address space "fragmentation" induced
by elfhack. The work around worked, at the expense of some added
complexity.
It was used for B2G only, and has effectively been unused since B2G was
retired.
Differential Revision: https://phabricator.services.mozilla.com/D9622
--HG--
extra : moz-landing-system : lando
This is the equivalent of the rustc-workspace-hack used by the rust build to
ensure cargo and RLS see the same set of features for dependencies so that
these dependencies may be reused by invocations of cargo for these two
projects. The trivial crate added specifies the union of the set of
features activated for a particular crate for each time it appears in the
dependency tree so that cargo will understand these dependencies to be
re-usable across cargo implementations. This eliminates re-building jsrust
and some of its dependencies twice, and reduces the number of crates compiled
in the tree by about 90 in testing on linux.
Differential Revision: https://phabricator.services.mozilla.com/D9041
--HG--
extra : moz-landing-system : lando
The cctools-port linker links against libraries from clang (for LTO),
which have different SONAMEs depending on the clang version. Which means
the linker needs to be used along the same version of clang it was built
against. Thus we also make it depend on linux64-clang-7.
But changing the dependency is not enough, cf. bug 1471905, so also
touch its build script, which it turns out, we need to do anyways
because llvm-dsymutil was renamed to dsymutil.
Relatedly, all toolchains that are built using cctools-port need to use
linux64-clang-7 too.
Building compiler-rt 7 with the OSX 10.11 SDK fails because of some
newer APIs being used in compiler-rt for xray, but this is not a feature
we use, so disable that.
Differential Revision: https://phabricator.services.mozilla.com/D6766
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
While we do have some uses of @depends-function comparison in some
templaces, related to host/target, we ought to be using `is` comparisons
rather than `==` anyways, so we switch those, and prevent other kinds of
comparisons being used at all.
This unveils the one noted in
https://phabricator.services.mozilla.com/D7713?id=21357#inline-30414
(and surprisingly only that one), that we remove entirely since it was
doing nothing in practice. Bug 1492305 will have to add it back in a
proper form.
Differential Revision: https://phabricator.services.mozilla.com/D8501
--HG--
extra : moz-landing-system : lando
This commit adds some documentation about build telemetry
to the build system documentation. This doc should be used
as a reference during opt-in to build system telemetry,
and includes paths to the relevant files for users to audit
independently. Documentation regarding the schema types and
object properties was generated by the `jsonschema2rst` tool,
available on PyPI.
Differential Revision: https://phabricator.services.mozilla.com/D8030
--HG--
extra : moz-landing-system : lando
If scandir is already present on the system the attempt to import the
c helper library will currently find the c helper from the system
install which may well be an outdated verion, so causing mach to
break. To solve this this patch does two things:
* Stops importing scandir in files that are run unconditionally when
invoking mach. This is generally considered good for performance
reasons.
* Installs the vendored scandir into the virtualenv for `mach lint`
rather than trying to import it directly from the source tree and so
not getting the c helper library.
Differential Revision: https://phabricator.services.mozilla.com/D8379
--HG--
extra : moz-landing-system : lando
This also requires the 64-bits rust compiler and some build system
tweaks.
And since we make the 32-bits builds cross-compiles on CI, we also need
to adjust the MSVC build mozconfigs such that the host compiler points
to the right MSVC cl. Likewise, the DIA SDK is used for host things, so
use the 64-bits version or it.
Differential Revision: https://phabricator.services.mozilla.com/D7845
--HG--
extra : moz-landing-system : lando
Running rustc with an open fd 4 sometimes causes it to fail with an obscure
error when it tries to connect to a job server on that fd. Closing the fd
solves the problem.
close_fds does what we need, and is the default value in Python 3, but not
in Python 2.
Differential Revision: https://phabricator.services.mozilla.com/D8167
--HG--
extra : rebase_source : d94447019e3e698d7cf2c293b0a9b99769cf316a
This patch adds two new actions to virtualenv_packages.txt processing:
windows and !windows. The former processes the rest of the action only on
Windows, and the latter processes it only on non-Windows.
These new features are used in virtualenv_packages.txt to use the
path to the unpacked Windows psutil wheel when on Windows, and build psutil
from source and use that path on other platforms.
This fixes the long-standing problem of not having psutil available on most
Windows systems (since they don't have the right set of Visual C++ build tools).
Differential Revision: https://phabricator.services.mozilla.com/D3437
--HG--
extra : moz-landing-system : lando
Scandir is a faster implementation of os.listdir since it caches file metadata
as it works. Using listdir and then calling things like os.path.isfile after
the fact will result in multiple system calls. Whereas with scandir, there will
only be a single system call per file.
Scandir is part of the stdlib in Python 3.6+, so the following can be used for
Python 2/3 compatible code:
try
from os import scandir, walk
except ImportError:
from scandir import scandir, walk
Differential Revision: https://phabricator.services.mozilla.com/D7738
--HG--
extra : moz-landing-system : lando
The incorrect LEGACY_BUILD_ID will be fixed in a subsequent changeset.
We must add https://www.mozilla.org/ to server-locations.txt and regenerate the mochitest certificates [1] because the new navigator.buildID test pretends to load content from https://www.mozilla.org/.
[1] https://searchfox.org/mozilla-central/source/build/pgo/certs/README
Differential Revision: https://phabricator.services.mozilla.com/D7982
--HG--
rename : dom/tests/mochitest/bugs/test_bug351601.html => dom/tests/mochitest/bugs/test_navigator_buildID.html
extra : rebase_source : 1deb142930f1a7a570cf719c4cb2bed8adfeabe2
extra : source : 408bff32f9623513a271cdf043d11ba6d1318e03
Mike Hommey
Csoregi Natalia
Jeff Gilbert
Kartikaya Gupta
Chris Manchester
Tom Ritter
Margareta Eliza Balazs
Nick Alexander
Tom Prince
Chris Peterson
Dorel Luca
Benjamin Bouvier
Cosmin Sabou
David Major
Connor Sheehan
Narcis Beleuzu
James Graham
Tiberius Oros
Kris Maglione
Dave Hunt
Ted Mielczarek
Andrew Halberstadt
Emilio Cobos Álvarez
Sylvestre Ledru
Brindusan Cristian
Noemi Erli