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>

1 files changed, 18 insertions, 3 deletions

diff --git a/configure.ac b/configure.ac
index 9d97f42c4030..224faea12abf 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4625,10 +4625,10 @@ check_use_ld()
             fi
         else
             # I tried to use gcc's '-B<path>' and a directory + symlink setup in
-	    # $BUILDDIR, but libtool always filtered-out that option, so gcc wouldn't
-	    # pickup the alternative linker, when called by libtool for linking.
+            # $BUILDDIR, but libtool always filtered-out that option, so gcc wouldn't
+            # pickup the alternative linker, when called by libtool for linking.
             # For mold, one can use LD_PRELOAD=/usr/lib/mold/mold-wrapper.so instead.
-	    AC_MSG_ERROR([A linker path is just supported with clang, because of libtool's -B filtering!])
+            AC_MSG_ERROR([A linker path is just supported with clang, because of libtool's -B filtering!])
         fi
     fi
     use_ld_fail_if_error=$2
@@ -12966,6 +12966,21 @@ then
         if test ! -f "${qt5_platformsdir}"/libqwasm.a -o ! -f "$QT5_PLATFORMS_SRCDIR"/wasm_shell.html; then
             AC_MSG_ERROR([No Qt5 WASM QPA plugin found in ${qt5_platformsdir} or ${QT5_PLATFORMS_SRCDIR}])
         fi
+
+        EMSDK_LLVM_NM="$(em-config EMSCRIPTEN_ROOT)"/../bin/llvm-nm
+        if ! test -x "$EMSDK_LLVM_NM"; then
+            AC_MSG_ERROR([Missing llvm-nm expected to be found at "$EMSDK_LLVM_NM".])
+        fi
+        if test ! -f "${qt5_libdir}"/libQt5Gui.a; then
+            AC_MSG_ERROR([No Qt5 WASM libQt5Gui.a in ${qt5_libdir}])
+        fi
+        QT5_WASM_SJLJ="`${EMSDK_LLVM_NM} "${qt5_libdir}"/libQt5Gui.a 2>/dev/null | $GREP emscripten_longjmp`"
+        if test "$ENABLE_WASM_EXCEPTIONS" = TRUE -a -n "$QT5_WASM_SJLJ"; then
+            AC_MSG_ERROR(['emscripten_longjmp' symbol found in libQt5Gui.a (missing '-s SUPPORT_LONGJMP=wasm'). See static/README.wasm.md.])
+        fi
+        if test "$ENABLE_WASM_EXCEPTIONS" != TRUE -a -z "$QT5_WASM_SJLJ"; then
+            AC_MSG_ERROR(['emscripten_longjmp' symbol not found in libQt5Gui.a. You probably use an incompatible Qt build with '-s SUPPORT_LONGJMP=wasm'.])
+        fi
     fi
 
     QT5_CFLAGS="-I$qt5_incdir -DQT_CLEAN_NAMESPACE -DQT_THREAD_SUPPORT -DQT_NO_VERSION_TAGGING"