GNU readelf isn't available as consistently as I assumed across SunOS,
and it can be named different things on different illumos distros (some call
it readelf, others call it greadelf, etc), so it's safer to use elfdump.
This is a fairly easy fix, just kind of annoying.
Generating OS-appropriate mapfiles from a provided SYMBOL_FILE is
apparently required to work with newer ffvpx. Nothing else in our
codebase actually seemed to require it. Also seems to reduce the amount
of console spam I see relating to symbol visibility during the build
process, and I think it even makes libxul.so link a bit faster.
Signed-off-by: athenian200 <athenian200@outlook.com>
- Update make_unicode to output SpecialCasing
- Handle special casing
- Use realloc instead of malloc when resizing a newly created string buffer
Based-on: m-c 1318403, 1431957
Vim control lines were re-introduced or not entirely cleaned up.
This nukes them again.
Removing from the rest of js, caps, chrome, config, devtools, docshell,
image, intl. More to come.
Currently only Windows can take advantage of this.
The reason why the arrays of deunified sources are named like that in
Spidermonkey's moz.build is to avoid UnsortedErrors in python. There's probably
a better way to handle that, but I just want something that works for now.
And yes, the deunified sources will be reunified if LTO is disabled.
It seems that if we're going to enable JS_SHARED_LIBRARY, we need ICU to be a
shared library too in order to prevent code duplication in mozjs.dll bloating
it to a whopping 21 MB.
This unfortunately means we have to fold icudata back to icu itself. But since
icudata is still separated from libxul (which is what really matters for #1451),
I think this is a fair compromise.
Building ICU as shared is offered as an option via --enable-shared-icu. But
technically you really need --enable-shared-icu if you're going to use
--enable-shared-js. Unfortunately I can't make configure exit with an error if
MOZ_SHARED_ICU is not defined when JS_SHARED_LIBRARY is enabled, because options
are controlled by different configure scripts (icu is based on bash, while js is
based on python), and I have no idea how to pass MOZ_SHARED_ICU to js's
moz.configure.
Tag #62
Don't mark the .kPStaticModules section as relro for bfd, as the linkers on
Windows and Mac don't do this anyway.
Add a section insert of .kPStaticModules to config/expandlibs_exec.py, which
seems to be the primary cause of linking bustage on gold, lld, and mold.
Based on Mozilla bugs 1270140, 1504656, 1483545, and 1504334.
Took note of Mozilla bug 1379222 which changed GetPrototypeFromCallableConstructor
to GetPrototypeFromBuiltinConstructor.
There are many other changes I did myself since the initial implementation by
Mozilla wouldn't work with this codebase.
This allows us to use a greater rendering depth for exceedingly-deep DOM trees
in layout, better matching what mainstream browsers are capable of. Note that
for 32-bit Windows the stack size MUST be set to larger than the default or Bad
Things Will Happen™ - we use 1.5 MB for this as a carefully-tuned value.
This needs to be capped specifically for JS use because some JavaScript
obfuscators deliberately trigger stack overflows and would lock up the browser
otherwise as long as there's still stack space to abuse. For web compatibility
we therefore limit this to 2MB in JS only (3x for ASAN) while still allowing
a greater depth for the layout engine.
Including <cstdlib> must never trigger inclusion of "mozalloc.h", because the
first thing this one does is precisely to include <cstdlib>.
It is now the case that, in libc++ 9 and beyond, <cstdlib> includes <math.h>
which then tries to include <type_traits>, which the STL wrapper intercepts,
trying to load "mozalloc.h". Same problem happens with <limits>.
Fix pulled from: https://bugzilla.mozilla.org/show_bug.cgi?id=1594027.
This removes speech recognition, pocketsphinx, training models
and the speech automated test interface.
This also re-establishes proper use of MOZ_WEBSPEECH to work
for the speech API (synthesis part only) that was a broken mess
before, with some synth parts being always built, some parts
being built only with it enabled and recognition parts being
dependent on it. I'm pretty sure it'd be totally busted if you'd
ever have tried building without MOZ_WEBPEECH before.
Tested that synthesis still works as-intended.
This resolves#1538
