desktop/source/app/sofficemain.cxx | 6 ++++++
static/README.wasm.md | 6 +++++-
2 files changed, 11 insertions(+), 1 deletion(-)
New commits:
commit 77129fbb74bcefde4551d494f029169e7c6026e3
Author: Stephan Bergmann <stephan.bergm...@allotropia.de>
AuthorDate: Wed May 15 15:24:48 2024 +0200
Commit: Stephan Bergmann <stephan.bergm...@allotropia.de>
CommitDate: Tue May 28 15:14:12 2024 +0200
Emscripten: Add hack to prepare for --enable-wasm-exceptions
(...which will be beneficial, in turn, to implement exception handling in
the
work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge).
Once setting --enable-wasm-exceptions, plus the corresponding
-sSUPPORT_LONGJMP=wasm in qt5, I indeed started to see the "RuntimeError:
null
function or function signature mismatch" that was already mentioned in
static/README.wasm.md. I could track it down to the early destruction of
the
aDesktop local variable in soffice_main, as I now explain there. However,
it
beats me why that variable gets destroyed early. The
desktop::Desktop::~Desktop
dtor claims to be called from within main -> soffice_main ->
desktop::Desktop::~Desktop, but at a time when the call to main ->
soffice_main
-> SVMain has not yet returned. There also does not appear to be any C++
exception handling stack unwinding going on. (It could be related somehow
to
-sSUPPORT_LONGJMP=wasm, I don't know.) And everything appears to just work
fine
after turning that aDesktop local variable into a (leaked) heap instance
instead, so go with that hack for now...
Change-Id: I8e00c988ee9a44fd3befbe41c844eec050f0e509
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167694
Reviewed-by: Stephan Bergmann <stephan.bergm...@allotropia.de>
Tested-by: Jenkins
diff --git a/desktop/source/app/sofficemain.cxx
b/desktop/source/app/sofficemain.cxx
index 73ac6e24cfe4..33881784d45c 100644
--- a/desktop/source/app/sofficemain.cxx
+++ b/desktop/source/app/sofficemain.cxx
@@ -63,7 +63,13 @@ extern "C" int DESKTOP_DLLPUBLIC soffice_main()
#endif
tools::extendApplicationEnvironment();
+#if defined EMSCRIPTEN
+ //TODO, see "Experimental (AKA currently broken) WASM exception + SjLj
build" in
+ // static/README.wasm.md:
+ new desktop::Desktop();
+#else
desktop::Desktop aDesktop;
+#endif
// This string is used during initialization of the Gtk+ VCL module
Application::SetAppName( u"soffice"_ustr );
diff --git a/static/README.wasm.md b/static/README.wasm.md
index 5397e2124d16..97be5a14123b 100644
--- a/static/README.wasm.md
+++ b/static/README.wasm.md
@@ -122,7 +122,11 @@ 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. Unfortunately the build also needs a Qt build with
+job scheduler code (concretely: the call to
`pSchedulerData->mpTask->UpdateMinPeriod` in
+`Scheduler::CallbackTaskScheduling` in vcl/source/app/scheduler.cxx being a
pure virtual call on a
+destroyed `desktop::Desktop::m_firstRunTimer` instance, because
`desktop::Desktop aDesktop` in
+`soffice_main` in desktop/source/app/sofficemain.cxx gets destroyed early, for
unclear reasons).
+Unfortunately 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
