config.guess doesn't actually figure out the real host system on
Windows. All it does is end up finding the CPU for which the msys used
for the shell is built for. Which has the unfortunate effect that if you
build on a 64-bits host, configure pretends the host is 32-bits.
So instead, rely on some environment variables that should be set
mostly everywhere, and derive the corresponding triplet.
This has two effects:
- configure now knows that the host is 64-bits when it is.
- consequently, configure will build a 64-bits Firefox on 64-bits hosts
by default (since by default, the target is derived from the host), and
that's actually a desired side effect.
Depends on D17620
Differential Revision: https://phabricator.services.mozilla.com/D17621
--HG--
extra : moz-landing-system : lando
- We assume the output from config.guess is sufficiently normalized for
our needs.
- If we partially derive the target from the host (with only the cpu
given for --target), we assume the derived value doesn't need
canonicalization.
Differential Revision: https://phabricator.services.mozilla.com/D17620
--HG--
extra : moz-landing-system : lando
In fact, "simply" use whatever python configure does to find a shell to
execute config.guess and config.sub, and get both the mozconfig content
and the real, canonicalized target alias. This has the side effect of
making builds with --target=$cpu use a complete obj-$cpu-$os default
objdir instead of obj-$cpu. This will also allow to change the
host-guessing logic without having to duplicate code.
Differential Revision: https://phabricator.services.mozilla.com/D17618
--HG--
extra : moz-landing-system : lando
which, at this point, is only the AC_SUBST, so we don't even need to
give it to old-configure anymore.
Depends on D17207
Differential Revision: https://phabricator.services.mozilla.com/D17208
--HG--
extra : moz-landing-system : lando
which, at this point, is only the AC_SUBST, so we don't even need to
give it to old-configure anymore.
Depends on D17207
Differential Revision: https://phabricator.services.mozilla.com/D17208
--HG--
extra : moz-landing-system : lando
Because old-configure is only refreshed when, essentially,
old-configure.in changes, hardcoded (absolute) paths don't necessarily
match the build environment of the current build.
So instead, use an environment variable that we pass from python
configure when invoking old-configure.
Also do dummy changes to old-configure.in so that old-configure is
refreshed at least once to get the environment-based value.
Differential Revision: https://phabricator.services.mozilla.com/D17077
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Rust ships with some natvis files that enable nicer display of Rust standard
library types in Microsoft's debuggers. rustc will add the right linker
options to include them when it invokes the linker but since we don't link
libxul with rustc we need to explicitly pass them to the linker ourselves.
This change locates all natvis files in the Rust sysroot and adds them
to the libxul link line.
Differential Revision: https://phabricator.services.mozilla.com/D16544
--HG--
extra : moz-landing-system : lando
Add a dummy change to old-configure.in so that old-configure is
force-refreshed.
Differential Revision: https://phabricator.services.mozilla.com/D16797
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Before bug 1322025, running configure --help along --host and/or
--target would show the options that are specific to the
host/target/cross-compilation (e.g. those with when=target_is_windows)
which was convenient. Bug 1322025 unfortunately broke that, and this
restores the feature.
Differential Revision: https://phabricator.services.mozilla.com/D16673
--HG--
extra : moz-landing-system : lando
Instead, use the actual log file name as configured through python
logging. This doesn't make a practical difference now, but will when
subconfigure logs to the toplevel log.
Depends on D16666
Differential Revision: https://phabricator.services.mozilla.com/D16667
--HG--
extra : moz-landing-system : lando
We're going to want to log some more. At the moment, this just adds the
output of subconfigure to top-level config.log, but this will become
more useful down the road.
Depends on D16665
Differential Revision: https://phabricator.services.mozilla.com/D16666
--HG--
extra : moz-landing-system : lando
Back when those were added, option defaults could not indirectly depend
on `target` or `host`, but that changed with bug 1322025.
As a side effect, this allows to turn them into straight js_options
without resorting to the manual add_old_configure_arg.
Differential Revision: https://phabricator.services.mozilla.com/D16664
--HG--
extra : moz-landing-system : lando
Use an I/O wrapper on the configure output handler to add the "js/src>"
prefix.
Depends on D16643
Differential Revision: https://phabricator.services.mozilla.com/D16644
--HG--
extra : moz-landing-system : lando
It was manually removed because autoconf's AC_OUTPUT_SUBDIRS passes it,
but we've not been using AC_OUTPUT_SUBDIRS for a while.
Depends on D16637
Differential Revision: https://phabricator.services.mozilla.com/D16638
--HG--
extra : moz-landing-system : lando
The code only actually handles autoconf 2.5 cache, and was useful when
we have such subconfigures, that would die when things changed in ways
that would make the subconfigure abort on its own. But we have no such
things left, and while we may want to clear the cache for old-configure
(for e.g. bug 1520232), this is not helping to get there.
Differential Revision: https://phabricator.services.mozilla.com/D16636
--HG--
extra : moz-landing-system : lando
Instead, include the module and inline its main function.
Depends on D16622
Differential Revision: https://phabricator.services.mozilla.com/D16623
--HG--
extra : moz-landing-system : lando
This happens to remove the last use of perl from configure.
Depends on D16621
Differential Revision: https://phabricator.services.mozilla.com/D16622
--HG--
extra : moz-landing-system : lando
The File class is now used only in one place, only for its mtime
property, which can be replaced with os.path.getmtime.
Depends on D16402
Differential Revision: https://phabricator.services.mozilla.com/D16403
--HG--
extra : moz-landing-system : lando
Because subconfigure.py is only used for js/src and we're not going to
add any more subconfigures, we can hardcode js/src into the script, and
remove the branches that aren't taken as a consequence.
Depends on D16382
Differential Revision: https://phabricator.services.mozilla.com/D16402
--HG--
extra : moz-landing-system : lando
It was useful to run the prepare phase and the actual subconfigure
separately, but it's not anymore after all the recent simplications.
Depends on D16381
Differential Revision: https://phabricator.services.mozilla.com/D16382
--HG--
extra : moz-landing-system : lando
Because we only ever run one subconfigure, the machinery to execute
several is not useful anymore. Inlining it allows to simplify the code
too, because it doesn't need to be generic anymore. This also removes
the last remaining bits of acwinpaths.m4.
Also remove now unused support for --list in build/subconfigure.py.
Depends on D16380
Differential Revision: https://phabricator.services.mozilla.com/D16381
--HG--
extra : moz-landing-system : lando
We only run it for js/src now, so get_config_files always returns empty lists.
Depends on D16378
Differential Revision: https://phabricator.services.mozilla.com/D16379
--HG--
extra : moz-landing-system : lando
This only affects the compiler version in the build system; not the
version reported by the compiler.
--HG--
extra : histedit_source : 37fc1a2090d872ca5e95d022e9f93b620b2d8dbb
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
When doing cross-compiles for Desktop, system pkg-config is going to be
looking for .pc files for the host, but systems setup for cross-compiles
come with a toolchain-prefixed pkg-config, which we should be looking
for.
Differential Revision: https://phabricator.services.mozilla.com/D16318
--HG--
extra : moz-landing-system : lando
MOZ_D3D_CPU_SUFFIX and MOZ_HAS_WINSDK_WITH_D3D are not used in the
build, and nothing includes d3d10.h except some angle code in a
preprocessed branch that is only taken for a macro we never define,
so we don't move the code corresponding to those. We also simplify the
detection code, which is convoluted now that it doesn't search for
multiple different DLLs.
Differential Revision: https://phabricator.services.mozilla.com/D16295
--HG--
extra : moz-landing-system : lando
In bug 1494022 there are problems using an SDK that is too new, which
can cause developers to spend many hours debugging an issue that we
could've checked up front.
This patch gets the version from the SDKSettings.plist file at the root
of the SDK directory, and checks it against min and max supported
versions.
The current min version is 10.11, since that is what we build with in
automation. The current max version is 10.13, since 10.14+ currently has
an issue with a black screen at startup.
Differential Revision: https://phabricator.services.mozilla.com/D16140
--HG--
extra : moz-landing-system : lando
Because MSVC compilers only support one architecture, we need to search
"cl" in different toolchain search paths for each of the host and
target, especially when they are different.
Likewise for the library paths for the linker. Ideally we'd pass
-LIBPATH both for host and target, but that has implications for rust
that I don't want to have to figure just now.
Depends on D15263
Differential Revision: https://phabricator.services.mozilla.com/D15264
--HG--
extra : moz-landing-system : lando
While it was preferable to use lld-link with msvc for performance
reasons when we defaulted to compile with msvc, now that we build with
clang-cl by default, it's now better to use msvc's linker when using
msvc's compiler, especially for aarch64, which is the last place where
we actually need msvc.
Differential Revision: https://phabricator.services.mozilla.com/D15262
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
LLVM_PROFDATA needs the toolchain search dir, per bug 1515579.
Also, most of the options actually don't do anything useful with
artifact builds. In fact, the only one that artifact builds would need
is MOZ_PGO. So we move to options back to toolchain.configure, somewhere
late enough ; except MOZ_PGO, that we move to the top-level
moz.configure (because we don't need a separate file for one option).
Differential Revision: https://phabricator.services.mozilla.com/D16152
--HG--
extra : moz-landing-system : lando
Firefox uses multiple processes. It has intentional leaks, and when
running with ASAN, we have suppressions to eliminate those. When running
ASAN builds through CI tests, when Firefox exits, each of the processes
(parent and child) exits and goes through its leaks and when there are
(which is a given), the ASAN runtime runs llvm-symbolizer to symbolicate
and match against suppressions. So each process runs llvm-symbolizer. At
the same time.
Some of the addresses to symbolicate are in libxul. Which contains all
DWARF info, making it a ~1GB monster. Oh, and because you're lucky,
things align perfectly such that libxul size is a multiple of the page
size. That makes llvm-symbolizer pread() the file instead of mmap()ing
it. Did I say there are multiple processes? So suddenly you have n
processes simultaneously allocating and filling 1GB of memory each, on
CI machines that have enough memory for the job they usually run, but
not enough for a sudden rush of n GB.
And things go awry. When you're lucky and the OOM killer didn't take
care of killing the CI entirely, symbolication couldn't happen and the
suppressions are not matched, and leaks are reported.
This all turns out it originates in how llvm-symbolicate chooses between
pread() and mmap(), which turns out is just defaults not being made for
binary files.
Differential Revision: https://phabricator.services.mozilla.com/D16010
--HG--
extra : moz-landing-system : lando
In bug 1514288 we started to save the output from running Firefox during
PGO builds into log files, but they aren't correctly uploaded if the run
fails. This presents a problem for categorizing failed PGO builds if the
profileserver returns an error code (eg: bug 1517939), since the error
messages could be hidden away in log files that aren't uploaded.
Instead, we can generate them directly into the artifacts directory so
that they are always uploaded. Additionally, the log files are displayed
if the run fails so that the error messages are displayed in the log for
easier bug categorization.
Differential Revision: https://phabricator.services.mozilla.com/D15881
--HG--
extra : moz-landing-system : lando
Instead of per-document. This also allows to reuse this thread-pool if needed
for other stuff, like parallel CSS parsing (#22478), and to share more code with
Gecko, which is always nice.
This cherry-picks https://github.com/servo/servo/pull/22487, with a few minor
fixes to the build that are landing as part of the sync associated to this bug,
and an lsan exception tweak to point to the right module since it's moving.
The output from running the browser during PGO builds can have innocuous
error messages in them, but show up in treeherder as potential messages
to include when filing bugs. We can just save the output from these runs
as files and upload them as artifacts instead, so they don't show up in
the build log but are available for inspection if necessary.
MozReview-Commit-ID: 3VdVCKVkZNI
Differential Revision: https://phabricator.services.mozilla.com/D15154
--HG--
extra : moz-landing-system : lando
In bug 1259382, some workarounds were added to make the build system
alter PATH and not use absolute paths for toolchain programs, because
autoconf and the build system doesn't deal with spaces in those very
well. But later in bug 1290040, we made find_program return Windows
short paths (without spaces), which alleviates the need for those
workarounds.
We still, however, and unfortunately, need to alter PATH to account for
the fact that MSVC DLLs are not necessarily alongside the compiler
executables...
Depends on D15181
Differential Revision: https://phabricator.services.mozilla.com/D15182
--HG--
extra : moz-landing-system : lando
Like for other windows platforms. This currently doesn't make a
difference, but will with next change.
Differential Revision: https://phabricator.services.mozilla.com/D15181
--HG--
extra : moz-landing-system : lando
We remove --disable-libjpeg-turbo because that's only useful when Yasm
is too old, and the required version is now almost 8 years old, so we
can reasonably require people to upgrade rather than workaround with a
--disable option.
The valid_yasm_version function can seem overkill, but that's because
future moves of other things to python configure will pile up.
Differential Revision: https://phabricator.services.mozilla.com/D15184
--HG--
extra : moz-landing-system : lando
Now that we're not even building host static libraries, we don't need
variables for the tools used to build them.
Ironically, we weren't even running HOST_RANLIB.
Depends on D15172
Differential Revision: https://phabricator.services.mozilla.com/D15173
--HG--
extra : moz-landing-system : lando
So far, the main subject of cross-compiles was to cross compile from one
OS to another (e.g. {linux,osx} -> android), but there are a few useful
cases where the OS doesn't change, and, with --host being guessed, we
can just have developers pass --target=$cpu instead of a complete
target triplet. This can be useful to do x86 Linux builds on x86-64
Linux hosts, or aarch64 Windows builds on x86-64 Windows hosts.
Differential Revision: https://phabricator.services.mozilla.com/D15063
--HG--
extra : moz-landing-system : lando
Remove the version check for WINDRES, because, as per bug 454112, it
didn't actually work, and, making it work actually causes problems
because llvm's windres, used with mingw clang, has version 0.1.
Differential Revision: https://phabricator.services.mozilla.com/D15070
--HG--
extra : moz-landing-system : lando
vswhere only searches in Community, Professional and Enterprise, but one can
also install BuildTools only, which has a different product name.
Differential Revision: https://phabricator.services.mozilla.com/D15056
--HG--
extra : moz-landing-system : lando
It will be useful to run tests like try_compile, with different flags and different
kinds of sources.
Depends on D14949
Differential Revision: https://phabricator.services.mozilla.com/D14950
--HG--
extra : moz-landing-system : lando
Although this task technically doesn't build a toolchain, the set of
steps it needs to do is very similar to what a toolchain build does, so
we're shoehorning this task into the toolchain kind. The task basically
runs `cargo vendor` on the gfx/wr/Cargo.lock file (if/when it changes)
and exports a tarball of the resulting vendored crates. This allows
downstream tasks that build stuff in gfx/wr to not have to re-fetch
these crates from crates.io on every test run.
Differential Revision: https://phabricator.services.mozilla.com/D14406
--HG--
extra : moz-landing-system : lando
The SQLite in Debian 7 (3.7.13) lacks support for common table
expressions (the WITH keyword), which was introduced in SQLite
3.8.3. The Mercurial SQLite storage backend currently relies on
CTEs. Even if a future Mercurial doesn't require CTE, it is likely
that it will still use CTE if available for performance reasons.
So, it is in our best interest to give Mercurial access to a
modern SQLite. Plus, using a modern SQLite and avoiding potential
bugs in old versions seems prudent.
This commit introduces a SQLite package backport for Debian 7
so we can use the new SQLite feature. We had to minimally patch
the build to work with an older version of TCL that isn't using
multiarch.
I observed libsqlite3 being installed as part of building various
other packages (such as Python). I initially added the package as
a dependency so packages would be built against a more modern
SQLite. But glandium doesn't believe it matters, since nothing
should be doing build-time feature detection. Python is the most
important downstream package (since Mercurial uses its SQLite).
I audited the CPython build system and did not see any build-time
SQLite feature detection or version sniffing. So I think we'll be
fine building against an older SQLite.
Differential Revision: https://phabricator.services.mozilla.com/D14194
--HG--
extra : moz-landing-system : lando
We don't care anymore: the Gradle build fetches an appropriate version
of the build-tools package, and the one build-tool we actually use --
zipalign -- isn't version sensitive.
Differential Revision: https://phabricator.services.mozilla.com/D14290
--HG--
extra : moz-landing-system : lando
There's no need -- it will be fetched by Gradle when needed. The only
wrinkle is that the user might be asked to confirm license agreements,
which could be a hassle (and could cause problems in CI, but there we
install relevant platforms in advance).
Differential Revision: https://phabricator.services.mozilla.com/D14288
--HG--
extra : moz-landing-system : lando
The build system no longer invokes these directly: they're all fetched
and invoked by Gradle and its plugins.
Differential Revision: https://phabricator.services.mozilla.com/D14287
--HG--
extra : moz-landing-system : lando
CPP/HOST_CPP were probably not necessary already, but now that we leave
it to configure to figure out the appropriate compiler flags, we don't
need to set HOST_CC/HOST_CXX to remove the flags from CC/CXX.
Differential Revision: https://phabricator.services.mozilla.com/D14382
Rather than manually passing -isysroot to clang. Ideally, we shouldn't
need to fill BINDGEN_CFLAGS from the mozconfig, but we're not quite
there yet.
Differential Revision: https://phabricator.services.mozilla.com/D14381
Because we now set the sysroot include flags early in python configure,
we don't need to set CPP/CXXCPP. We also skip the explicit compiler test
because more complete tests follow anyways.
Differential Revision: https://phabricator.services.mozilla.com/D14380
This matches more closely cross toolchains prefixes (as can be seen in
e.g. media/libvpx/libvpx/README for x86_64-darwin*-gcc), and leaves it
to the build system to figure out the right --target to pass to clang on
its own.
Differential Revision: https://phabricator.services.mozilla.com/D14376
We're always setting -dead_strip on mac builds, per
cross-mozconfig.common, we might as well not do that and revert bug
638149, which disabled adding -dead_strip with LTO: that is apparently
not a problem anymore.
Differential Revision: https://phabricator.services.mozilla.com/D14373
Currently, when Firefox crashes when running the PGO profile, the error
is ignored, and the result is a build that is not optimized as expected.
So instead of such things going unnoticed, we make profileserver.py
return an error code, further failing the build.
Unfortunately, this does not make the output useful to know what went
wrong exactly, but the most important thing is that the build fails
instead of going through and leading to bad results.
Mike Hommey
Ryan VanderMeulen
Jan Henning
David Major
Chris Manchester
shindli
Cosmin Sabou
Ted Mielczarek
Brindusan Cristian
Emilio Cobos Álvarez
Margareta Eliza Balazs
Ehsan Akhgari
Tom Ritter
Dorel Luca
Mike Shal
Kris Maglione
Nick Alexander
Geoff Brown
Dustin J. Mitchell
Ciure Andrei
Razvan Maries
Narcis Beleuzu
Marco Bonardo
Noemi Erli
Sebastian Hengst
Kartikaya Gupta
Bogdan Tara
Gregory Szorc