solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk | 3 +++ static/README.wasm.md | 12 ++++++++++++ 2 files changed, 15 insertions(+)
New commits: commit e0178cfdba827dafcb192fec005ea45bd041c485 Author: Stephan Bergmann <[email protected]> AuthorDate: Sun Aug 18 15:45:26 2024 +0200 Commit: Stephan Bergmann <[email protected]> CommitDate: Sun Aug 18 17:43:51 2024 +0200 Emscripten: Document how Qt builds its own freetype, but we link against LO's Change-Id: I6413c64db3d50f163ee9cc4feda395a54aab3cf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172012 Reviewed-by: Stephan Bergmann <[email protected]> Tested-by: Jenkins diff --git a/static/README.wasm.md b/static/README.wasm.md index c69129303aa5..9d005fe7f286 100644 --- a/static/README.wasm.md +++ b/static/README.wasm.md @@ -102,6 +102,18 @@ Current Qt fails to start the demo webserver: <https://bugreports.qt.io/browse/Q Use `emrun --serve_after_close` to run Qt WASM demos. +Qt builds some 3rd-party libraries that it brings along (e.g., qt5/qtbase/src/3rdparty/freetype) and +compiles its own code against the C/C++ include files of those 3rd-party libraries. But when we +link LO, we link against our own versions of those libraries' archives (e.g., +workdir/UnpackedTarball/freetype/instdir/lib/libfreetype.a), not against the Qt ones (e.g., +$QT5DIR/lib/libqtfreetype.a). This mismatch between the include files that Qt is compiled against, +vs. the archive actually linked in, seems to not cause issues in practice. (If it did, we could +either try to make both Qt and LO link against e.g. -sUSE_FREETYPE from emscripten-ports, or we +could move Qt from a prequisite to a proper external/qt5 LO module built during the LO build, and +hack its configuration to build against LO's exernal/freetype etc. The former approach, building Qt +with -sUSE_FREETYPE, is even tried in qtbase/src/gui/configure.json, but apparently fails for +reasons not studied further yet, cf. Qt's config.log.) + ### Setup LO `autogen.sh` is patched to use emconfigure. That basically sets various commit 4f41c19a03072b8c0ab7e882eea55a7f51619ef7 Author: Stephan Bergmann <[email protected]> AuthorDate: Sun Aug 18 15:15:29 2024 +0200 Commit: Stephan Bergmann <[email protected]> CommitDate: Sun Aug 18 17:43:39 2024 +0200 Emscripten: Increase the main thread stack size At least when LO tries to download a document and UUIInteractionHelper::handleErrorHandlerRequest wants to show a MessageDialog via Qt, the stack grows relatively large, and gray_convert_glyph (workdir/UnpackedTarball/freetype/src/smooth/ftgrays.c) alone allocates on the stack a buffer of size FT_MAX_GRAY_POOL * sizeof(TCell) = 1024 * 16 = 16K, which causes (silent, due to no -sSTACK_OVERFLOW_CHECK=2) stack overflow. So (somewhat randomly) double the size of the main thread stack to 128K; but, at least for now, keep the default value of 64K for other threads (which would otherwise inherit the explicitly set -sSTACK_SIZE value via the -sDEFUALT_PTHREAD_STACK_SIZE=0 default). Change-Id: I96583f4af93c84b15c67f310068c5631fb129d40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172011 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <[email protected]> diff --git a/solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk b/solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk index 08ead6996a94..268d2dbf932e 100644 --- a/solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk +++ b/solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk @@ -17,6 +17,9 @@ gb_EMSCRIPTEN_LDFLAGS := $(gb_EMSCRIPTEN_CPPFLAGS) # Initial memory size gb_EMSCRIPTEN_LDFLAGS += -s TOTAL_MEMORY=1GB +# Double the main thread stack size, but keep the default value for other threads: +gb_EMSCRIPTEN_LDFLAGS += -sSTACK_SIZE=131072 -sDEFAULT_PTHREAD_STACK_SIZE=65536 + # To keep the link time (and memory) down, prevent all rewriting options from wasm-emscripten-finalize # See emscripten.py, finalize_wasm, modify_wasm = True # So we need WASM_BIGINT=1 and ASSERTIONS=1 (2 implies STACK_OVERFLOW_CHECK)
