Additionally update the version detection back to 10.5 and forward to 14.
Fill some parts with code from TenFourFox when changes are not obvious.
Using gcc 7 from MacPorts, the gcc 4.8 TenFourFox used is too old.
Don't use GNU as on MacPPC it is too old.
Fix struct/class sizes by limiting bool size.
We don't actually build this, the build system just generates the
ghost of a static lib that pulls in OS libs. Someone made a mistake
at Mozilla years ago that they have not noticed to this day. They
only ever built freetype2 on Android, GTK always used the system FT2.
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.
As far as I can tell, all this code is unused in our platform. GCC older than
7 didn't have the macro _GLIBC_RELEASE. As far as I can tell, using newer GCC
means you don't have to check for incompatible symbol versions in the build
system, not even if you are compiling with clang against GCC's libc.
These version checks were only used with --enable-stdcxx-compat,
which as far as I can tell no UXP application has ever relied on.
The only use case seems to have been building with clang against an
old version of GCC's libc that predates C++11, let alone C++17.
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.
This removes two variables in the build system: MOZ_ICU_DATA_ARCHIVE and
MOZ_SHARED_ICU.
Per discussion in PR #2164, it's now preferred to fold the ICU data into the new
shared library.
This effectively means --enable-shared-icu is no longer a thing. UXP apps must
update their packaging manifest to avoid breakage.
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.
I use this for quickly rebuilding and preprocessing the JS/XUL/CSS assets them without the need to recompile the IDL interfaces and other unnecessary items.
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.