For a while, now, ICU data has been stored as raw read-only data in rather
than a separate loadable library. This means the parts of ICU that can load
such a module are not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D82262
All the supported compilers support a GNU AS-like syntax, with only a
few details varying. It means we can use a single, simpler, way to
include the ICU data file, instead of 3 different ways, including one
that uses armasm64.exe, possibly wrapped with Wine.
Differential Revision: https://phabricator.services.mozilla.com/D82144
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
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
"confusables" feature:
- Used in 'unicode/uspoof.h' for spoofing detection.
"stringprep" feature:
- Used in 'unicode/usprep.h' for RFC 3454 string preparation.
"unames" feature:
- Used in 'unicode/uchar.h' for `u_charName` to retrieve the name of a Unicode character.
Differential Revision: https://phabricator.services.mozilla.com/D39664
--HG--
extra : moz-landing-system : lando
The hand-written assembly for libffi on aarch64/windows doesn't emit
unwind information. If we ever tried to unwind through these functions,
they'd look like leaf functions, which is decidedly not true and would
cause great pain.
For whatever reason, the original aarch64 libffi functions used
x21/x22/x23/x24 as their (callee-saved) scratch registers. This
convention works on windows as well, but the unwind information on
windows mandates that we start saving callee-saved registers starting
from x19, rather than x21. Rather than rewriting the assembly to use
x19/x20 instead of x21/x22, which would be a large change, we chose
instead to simply save/restore extra registers in the prolog/epilog.
This change does make the stack frame sizes slightly bigger, but an
extra 16 bytes in libffi stack frames should not matter.
The `-TC` change is necessary to make the compiler play nicely with .asm
file suffixes.
Differential Revision: https://phabricator.services.mozilla.com/D35714
--HG--
extra : moz-landing-system : lando
When we converted our libffi assembly preprocessing to use
`GENERATED_FILES`, we translated `sed 's%/F[dpa][^ ]*%%g'` to use the Python
regular expression `'F[dpa][^ ]*'`. Note that we missed the leading `/` in
the sed expression; omitting that leading slash causes no end of trouble if
you have particular expressions in your assembly file, such as
"FastFailCode". (I'm a little surprised this hasn't bitten us yet.)
The straightfoward fix is to add the leading slash.
But wait, the rabbit hole goes deeper. The actual bit from libffi's
`msvcc.sh` that this was trying to translate was:
```
echo "$cl -nologo -EP $includes $defines $src > $ppsrc"
"$cl" -nologo -EP $includes $defines $src > $ppsrc || exit $?
output="$(echo $output | sed 's%/F[dpa][^ ]*%%g')"
args="-nologo $safeseh $single $output $ppsrc"
echo "$ml $args"
eval "\"$ml\" $args"
result=$?
```
Note that the sed expression is operating on `$output`, which is a
completely *separate* thing from the output from the result of
preprocessing. In `msvcc.sh`, `$output` is actually some arguments that are
supposed to be passed to the assembler, per the above and the only place in
the script that sets `$output` to a non-trivial value:
```
-o)
outdir="$(dirname $2)"
base="$(basename $2|sed 's/\.[^.]*//g')"
if [ -n "$single" ]; then
output="-Fo$2"
else
output="-Fe$2"
fi
if [ -n "$assembly" ]; then
args="$args $output"
else
args="$args $output -Fd$outdir/$base -Fp$outdir/$base -Fa$outdir/$base"
fi
```
Presumably the sed expression is attempting to remove `-Fd` and friends from
`$args` instead of `$output`, but failing badly at doing so.
In any event, the regex substitution the script is doing is unnecessary and,
with the current code, actively harmful. Let's remove the regular
expression substitution entirely.
Differential Revision: https://phabricator.services.mozilla.com/D35705
--HG--
extra : moz-landing-system : lando
ICU changes the numbering system of date formats which include an era marker
to "jpanyear". "jpanyear" is a rule-based numbering system and therefore the
RBNF data for the Japanese locale now need to be included.
Differential Revision: https://phabricator.services.mozilla.com/D27340
--HG--
extra : moz-landing-system : lando
This is being changed in Firefox's build config rather than NSPR's
to avoid possibly introducing regressions into other NSPR users due
to bugs in MacOS's poll, such as the POLLPRI issue addressed in the
previous patch. (There is also a known bug when calling poll() with
zero descriptors, but PR_Poll already has code to call PR_Sleep instead
in that case.)
Depends on D21321
Differential Revision: https://phabricator.services.mozilla.com/D21322
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
Includes changes to support nasm's stricter include paths.
Supports falling back to yasm if nasm is missing.
Differential Revision: https://phabricator.services.mozilla.com/D9972
--HG--
extra : moz-landing-system : lando
The bulk of this patch is the new win64.asm, which is a more-or-less
direct copy of aarch64's sysv.S file, with modifications for armasm64's
peculiarities. The changes to ffi.c were minimal, mostly so that
arithmetic on `void*` conforms to the C standard.
Apparently the assembler was willing to accept the previous version, but
was unwilling to find the necessary symbols to link some JS code. This
version correctly quotes the data symbol and adds a little extra quoting
based on examining compiler-generated output.
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
libprio does not currently build with MSVC (since it only supports
C90 as a compiler), this is being worked on upstream at https://github.com/mozilla/libprio/issues/17
As we are almost certainly not going to ship Firefox build with MSVC anymore,
let's disable this to get it working on this Tier-2 platform.
Differential Revision: https://phabricator.services.mozilla.com/D4292
--HG--
extra : moz-landing-system : lando
This is tracked upstream at https://github.com/mozilla/libprio/issues/15
MozReview-Commit-ID: L5VWKdEitfB
--HG--
extra : rebase_source : c19472a8658c01a2edc69904e36a2c5409af1396
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
Mike Hommey
André Bargull
Anthony Ramine
Ricky Stewart
Narcis Beleuzu
Marco Bonardo
Mike Shal
Csoregi Natalia
Nathan Froyd
Cosmin Sabou
Brindusan Cristian
Sylvestre Ledru
shravanrn@gmail.com
Daniel Varga
championshuttler
Justin Wood
Ehsan Akhgari
Petr Sumbera
Jed Davis
Dorel Luca
Robert Helmer
David Major
Christian Holler
Alex Chronopoulos
Thomas Daede
Andrew Osmond
Tom Ritter
Ciure Andrei
Gurzau Raul
Karl Tomlinson
Jacek Caban