When -flto is enabled emscripten will generate "system libraries" cache, for all available libraries, including non-used ones.
This includes libGL.a, libal.a, libhtml5.a, which are not used in the project.
Disabling AUTONATIVE_LIBRARIES decreases compile time with -flto enabled.
Cherry-picked from: 741d41808d
Do link-time optimizations and pre-evaluate code.
-s EVAL_CTORS=1 has no change in output currently.
-flto increases output size after optimizations
Cherry-picked from: ae80c98914
Extracts default.woff2 from binary, embeds fonts.conf,
removes .data files on output.
Use --memory-init-file=0 to remove .mem files on output.
Specify fallbackFont to override default.woff2.
If lazyFileLoading is set to true, use FS.createLazyFile(). This is
off by default, as it depends on correct HTTP headers sent back.
Cherry-picked from: 7988397f91
ASS subtitles can embed fonts with a custom encoding in
their [Fonts] section. For historic reasons ass_set_extract_fonts
defaults to disabled, so we need to explicitly opt-in.
There’s currently also an issue, with embedded fonts outliving
their track, which can lead to indefinitely growing memory consumption
if not all memory fonts are cleared on track reinit.
However, ass_clear_fonts can only be safely called if the renderer
also has been released first. At this point it is simpler to just
reinit the whole library-renderer-track triplet and library inits
are not that costly anyway.
JSO never uses (non-embedded) memory fonts itself and does not expose
any way to add them so this does not constitute a user-visible change.
Even oct_add_font cannot be used by consumers of upstream JSO binaries.
Note: the JS pointers of the libass handles are updated in this patch,
but it appears they are actually never used.
Cherry-picked from: 6f2bbdb61f
The portable mkfifo approach works fine locally and worked fine in
initial GHA testing, but now it started to run into various stalling
issues on GHA. Presumably depending on whether the pipe is first written
to or read from and attempts to find a simple workaround for it failed.
Sometimes (but not always!) this is accompanied by an error like this:
cannot open ./__LICENSE_EXTRACT_QUEUE.tmp: Interrupted system call
So convert the script to bash and just use set -o pipefail.
Cherry-picked from: 94cfe111f8
Apparently licensecheck has a high startup cost, so merging invocations
promises a neat speedup. However, currently some "\x{....} cannot be
represented as ascii" error messages appear in our logs. If that happens
licensecheck exits with 255, which omits all following files of the
same invocation and also prompts `find -exec .. {} +` or `xargs` to not
spawn any more invocations. If we were to simply merge invocations by
one of those means it would result in an incomplete COPYRIGHT file.
Those encoding errors appear to be due to an ASCII locale being set in
the container, so override LC_ALL to an UTF-8 one. To further make this
bit more resilient ensure licensecheck errors are no longer ignored by
capturing and processing its exit code.
Cherry-picked from: cf04e0361a
As an intermediate measure improving build times with multiple jobs
until the toplevel Makefile can properly handle parallelism.
Cherry-picked from: e3e00035b1
The latter is required as it's picked up by buildsystems,
the former is only used once by us and can easily be replaced
by the latter.
Cherry-picked from: e2e315834e
They appear to have been commented out since the first public release
and it's not clear what they were intended for or if they'd even still
work with current emscripten.
Cherry-picked from: 4370e7b52b
Previously some builds used a hardcoded number of 8 and others
didn't set it at all falling back to a single threaded build.
This still isn't ideal though. What we actually want is to fix up
or Makefile to allow builders to pass the number of jobs to the toplevel
and then a buildserver can distribute the available jobs across the
targets allowing inter-target parallelism.
For now, this already is a clear improvement.
The fribidi build appears to have a borked dependency on generated
sources when running from a subdir, which resulted in parallel builds
sometimes failing. To fix this the relevant header is now generated
explicitly before other build steps.
Cherry-picked from: 89e899a462
emscripten already sets PKG_CONFIG_LIBDIR preventing non-wasm libraries
installed in the system to be detected (and it doesn't provide a way for
us to set _LIBDIR ourselves).
Cherry-picked from: e88b1645e0
The last released version of brotli we use, blocks the install target
when building with emscripten, which is why we currently need to
manually copy files of interest to their installed location.
This adds complexity and is prone to failure with future changes.
Upstream no longer blocks installations with emscripten since
ce222e317e
from 23.06.2021.
We could just bump the brotli version to latest master, but then our
already existing patch would need updating and from a quick look
it appears as if other things changed as well which might not all be
compatible with our baseline target out of the box. AN eventual new
release with release notes will hopefully detail the changes in a
more accessible form.
As a safe option, just backport the upstream commit as another patch.
We still need to normalise the static library names though.
Cherry-picked from: ab214a6fe2
Possibly it did something in older versions, in current ones only
the compiler set __EMSCRIPTEN__ macro is used in checks.
Cherry-picked from: e240038da7
The build currently warns about building an executable with an
object-file extension and recommends to use -c, -shared or -r
eventhough we already use -r.
I'm not sure what -r is supposed to do, but -c only compiles and not
links the input which should be exactly what we want here and using -c
gets rid of the warning without any apparent negative effects.
Cherry-picked from: 3ce0643440
We are bound to one toolchain and most results of the
config-time checks were ignored anyway. This is more
concise and doesn't require a configuration step.
Cherry-picked from: 25bd9261ab
This is likely more common action. Also updating submodules
usually involves updating our patches which can't be automated.
Cherry-picked from: fa25ef0d7e
