summaryrefslogtreecommitdiff
path: root/static
diff options
context:
space:
mode:
authorJan-Marek Glogowski <glogow@fbihome.de>2022-03-26 20:46:56 +0100
committerJan-Marek Glogowski <glogow@fbihome.de>2022-03-30 15:12:21 +0200
commit79365d6f5a3706da8464d564deee6bb54422c3d0 (patch)
treed3b89f7b5875759ef96d3a1125234bb531a57ba1 /static
parent21c24aa4fdea118ddda0b60e17486458c739375f (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.md22
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.* \