MozillaBuild 3.4's kernel name was `MINGW32_NT-6.2`, but the new
MozillaBuild's kernel name looks like `MSYS_NT-10.0-19044`.
Update existing first-party detection code to properly handle the modern
MSYS "kernel name" format.
Differential Revision: https://phabricator.services.mozilla.com/D140096
- AC_HAVE_FUNCS is an alias to AC_CHECK_FUNCS, so it is covered.
- Nothing uses HAVE___CXA_DEMANGLE, so we don't explictly set it,
although we do need the result of whether __cxa_demangle is supported.
- No moz.build uses MOZ_DEMANGLE_SYMBOLS, so we only `set_define` it.
- We leave dladdr in old-configure because it needs to move along other
dl* things.
- The hotfix for AC_CHECK_FUNC is however not needed for dladdr, so we
remove it.
- We replace the forced HAVE_LOCALECONV on Windows with a check shared
with all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D134858
- AC_HAVE_FUNCS is an alias to AC_CHECK_FUNCS, so it is covered.
- Nothing uses HAVE___CXA_DEMANGLE, so we don't explictly set it,
although we do need the result of whether __cxa_demangle is supported.
- No moz.build uses MOZ_DEMANGLE_SYMBOLS, so we only `set_define` it.
- We leave dladdr in old-configure because it needs to move along other
dl* things.
- The hotfix for AC_CHECK_FUNC is however not needed for dladdr, so we
remove it.
- We replace the forced HAVE_LOCALECONV on Windows with a check shared
with all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D134858
While the use of toml allows the flags to be separated, the split is
done via some shell shenanigans anyways, and servo's build.rs can
handle the same just fine.
Differential Revision: https://phabricator.services.mozilla.com/D121042
Bug 1690930 added sysroots that can be bootstrapped. With this change,
we allow --enable-bootstrap=install to pull the right sysroot for the
configured target, and --enable-bootstrap to update it if it was already
there.
Differential Revision: https://phabricator.services.mozilla.com/D104797
In Bug 1671424 we changed the way we configure firefox and it broke the codeql database
generation job. This job wraps the entire build process in a way similar to
codeql --command="./mach build"
Specifically, the previous way we executed the configure shell script made codeql
disable itself because it was named configure (codeql disables itself during
configuration.)
codeql injects via LD_PRELOAD, and it opens a configuration file and a logging file
(getting fd 3 and 4 respectively.)
autoconf grabs file descriptor 4 and uses it a temporary redirection point either
to a file or stdout. When it does so, it closes the original file descriptor 4 and
points it at the new location, which also affects the codeql code, resulting in
undesired logging output going into the configure script.
Because this file descriptor trick is only used to avoid duplicating a few lines of
code, I removed the trick and duplicated the code.
Differential Revision: https://phabricator.services.mozilla.com/D98642
Instead, we now run js/src/old-configure from the top-level configure
after having run old-configure and extracted a few variables to inherit
from it.
Because we're now running from the top-level, $_objdir is always the
top-level objdir, which simplifies some things. The topobjdir in
js/src/config.status, however, needs to stay in js/src because of the
build frontend expecting it there.
When running js/src/old-configure, we used to need some special
treatment for a large number of variables for historic reasons, where
we'd take values from the assigned values before running old-configure
for some, or from AC_SUBSTs after running old-configure.
Now that both old-configure and js/src/old-configure get the same
assignments from old-configure.vars, we don't need anything special for
the former. And only a few remaining variables still need manual work
for the latter.
One notable difference, though, is that the new code doesn't try to
avoid running js subconfigure, which added complexity, and was actually
error-prone.
Differential Revision: https://phabricator.services.mozilla.com/D92725
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
I think they're remnants from the past that we don't really need anymore.
And they're making things more complicated for some pending work of mine.
Differential Revision: https://phabricator.services.mozilla.com/D89687
The files are copied verbatim from upstream autoconf 2.13 (but only the
files we need) and old.configure is adapted to use the vendored version.
Differential Revision: https://phabricator.services.mozilla.com/D89554
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
For not-well-understood reasons, ld's `--gc-sections` discards a large number of the PGO bookkeeping structures that enable us to keep track of function counters, and the effect gets worse in object files generated by clang-10.
As much as I'd like to understand this better, the investigations take way too much time. As a path of least resistance, we can disable `--gc-sections` for the instrumentation phase of PGO builds. It won't harm anything since users never see those builds, and it will improve the performance of the optimized phase greatly.
Differential Revision: https://phabricator.services.mozilla.com/D78112
Version of NSS >= 3.27 have a pkg-config file. We're now requiring 3.53,
so while moving, just use pkg-config, which is simpler.
The old-configure check that rejected some untested platforms for
in-tree NSS is actually rejecting none: the accepted platforms cover all
the supported ones, so we remove that check.
And because building with system NSS without system NSPR doesn't make
sense, imply the latter when the former is used.
Differential Revision: https://phabricator.services.mozilla.com/D77428
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
As all versions of zlib >= 1.2.3.1 have a pkg-config file, and 1.2.3.1
is close to 14 years old, let's drop 1.2.3 and just use pkg-config, which
simplifies what we need to do dramatically.
Differential Revision: https://phabricator.services.mozilla.com/D77404
iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
Mitchell Hentges
Zhao Jiazhong
Mike Hommey
Marian-Vasile Laza
Nick Alexander
Cristian Tuns
Iulian Moraru
Tom Ritter
Razvan Maries
David Major
Narcis Beleuzu
Nathan Froyd
Bogdan Tara
Ricky Stewart