diff options
author | Jan-Marek Glogowski <glogow@fbihome.de> | 2022-03-26 20:46:56 +0100 |
---|---|---|
committer | Jan-Marek Glogowski <glogow@fbihome.de> | 2022-03-30 15:12:21 +0200 |
commit | 79365d6f5a3706da8464d564deee6bb54422c3d0 (patch) | |
tree | d3b89f7b5875759ef96d3a1125234bb531a57ba1 /static | |
parent | 21c24aa4fdea118ddda0b60e17486458c739375f (diff) |
WASM fix native EH build since Emscripten 3.1.6
Building LO with WASM native EH and Emscripten 3.1.6+, the link
fails with a missing "emscripten_longjmp" symbol. Actually the
old build was simply wrong, because the emscripten_longjmp
function is just used for the Emscripten SjLj and not the native
WASM SjLj implementation. Linking just worked, because the used
libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that
symbol, which 3.1.6 removed.
But since running the NEH build still fails early in the same way
then before in FF nightly 100 and Chrome (= failure in the LO job
scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop
m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError:
indirect call signature mismatch"), there is still no way to know,
if nothing else it missing. The Emscripten / JS EH build still
works without any code changes. And it's not the first call on
a job object that fails...
And unfortunatly, because Qt itself also uses libpng, it also uses
SjLj for error handling, like LO in the image import, so the Qt
build must also be patched to build with "-s SUPPORT_LONGJMP=wasm".
Simply enough to do (see README.wasm.md). LO's configure now
detects that symbol and will bail out on incompatible Qt and LO
build setup.
See https://github.com/emscripten-core/emscripten/issues/16572
Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Diffstat (limited to 'static')
-rw-r--r-- | static/README.wasm.md | 22 |
1 files changed, 19 insertions, 3 deletions
diff --git a/static/README.wasm.md b/static/README.wasm.md index 4ea67ad03e6e..4624e87605b7 100644 --- a/static/README.wasm.md +++ b/static/README.wasm.md @@ -87,9 +87,10 @@ Use `emrun --serve_after_close` to run Qt WASM demos. environment vars, especially `EMMAKEN_JUST_CONFIGURE`, which will create the correct output file names, checked by `configure` (`a.out`). -There's a distro config for WASM (work in progress), that gets your -defaults right (and currently disables a ton of 3rd party stuff which -is not essential). +There's a distro config for WASM, but it just provides --host=wasm32-local-emscripten, which +should be enough setup. The build itself is a cross build and the cross-toolset just depends +on a minimal toolset (gcc, libc-dev, flex, bison); all else is build from source, because the +final result is not depending on the build system at all. Recommended configure setup is thusly: @@ -107,6 +108,21 @@ FWIW: it's also possible to build an almost static Linux LibreOffice by just usi --disable-dynloading --enable-customtarget-components. System externals are still linked dynamically, but everything else is static. +#### Experimental (AKA currently broken) WASM exception + SjLj build + +You can build LO with WASM exceptions, which should be "much" faster then the JS +based Emscripten EH handling. For setjmp / longjmp (SjLj) used by the PNG and JPEG +libraries error handling, this needs Emscripten 3.1.3+. That builds, but execution +still fails early with a signature mismatch call to Task::UpdateMinPeriod in LO's +job scheduler code. Unfortunatly the build also needs a Qt build with +"-s SUPPORT_LONGJMP=wasm", which is incompatible with the JS EH + SjLj. + +The LO configure flag is simply an additional --enable-wasm-exceptions. Qt5 can +be patched in qtbase/mkspecs/wasm-emscripten/qmake.conf with the addition of + + QMAKE_CFLAGS += -s SUPPORT_LONGJMP=wasm + QMAKE_CXXFLAGS += -s SUPPORT_LONGJMP=wasm + ### "Deploying" soffice.wasm tar -chf wasm.tar --xform 's/.*program/lo-wasm/' instdir/program/soffice.* \ |