79365d6f5a
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> |
||
|---|---|---|
| .. | ||
| CPPUNIT_PLUGIN_EXPORT.patch.0 | ||
| disable-dynloading.patch | ||
| enable-win32-debug.patch | ||
| ExternalProject_cppunit.mk | ||
| Makefile | ||
| Module_cppunit.mk | ||
| order.patch.0 | ||
| README | ||
| rtti.patch.0 | ||
| unix.patch | ||
| UnpackedTarball_cppunit.mk | ||
| windows-arm64.patch.1 | ||
| windows.patch | ||
C++ port of the JUnit framework for unit testing. From [http://www.freedesktop.org/wiki/Software/cppunit/]