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
Previously we weren't passing the variables if we were compiling for Windows
when really we only want to do it if we're compiling with MSVC/clang-cl.
The MinGW-Clang build needs this.
Differential Revision: https://phabricator.services.mozilla.com/D3470
--HG--
extra : moz-landing-system : lando
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
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.
For "real" Windows-to-Windows cross compiles, the setting of
HOST_OUTOPTION is incorrect: it assumes that if we are cross-compiling,
we'll be using `-o ` (GNU-style) rather than `-Fo` (MSVC-style). Our
normal x86 Windows automation builds are technically not
cross-compiles (host and target are both x86 Windows), so this case has
never bothered us before. But when compiling for AArch64 Windows, we
are really doing a cross-compile, and so we need to be more careful
about how we set this option; otherwise, host compilations will
mysteriously fail because they won't produce any output.
Summary:
This patch ports xptcodegen.py over to the new perfecthash.py system, removing
some special-case code generators, and taking advantage of the easier-to-use
interface.
In addition, the code was changed to take advantage of the endianness
information from Part 2, allowing us to avoid having to perform endianness swaps
at runtime when hashing nsIDs.
Depends On D2616
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2618
The file is added both unconditionally and conditionally to no effect.
MozReview-Commit-ID: 4t57o0bTF9P
--HG--
extra : rebase_source : c5f7bbb20e094cd4f7a9fcd1e143da90069b73b6
The file is added both unconditionally and conditionally to no effect.
MozReview-Commit-ID: JBZKN2qRf73
--HG--
extra : rebase_source : 74b601ae1d64f8ed7a47b02f79cbef66ac606abc
