diff options
| author | Stephan Bergmann <stephan.bergmann@allotropia.de> | 2024-01-26 14:12:31 +0100 |
|---|---|---|
| committer | Stephan Bergmann <stephan.bergmann@allotropia.de> | 2024-01-29 19:51:57 +0100 |
| commit | b476dccd11a1f9d7f39876ad23dd3e14c6671909 (patch) | |
| tree | 6e0f3e4f71ab24997b72db4cf7e26d7d659c69f7 /RepositoryFixes.mk | |
| parent | make chart-source dialog async (diff) | |
| download | core-b476dccd11a1f9d7f39876ad23dd3e14c6671909.tar.gz core-b476dccd11a1f9d7f39876ad23dd3e14c6671909.zip | |
Experimental support for latest Emscripten (and Qt6)
What I'm after in the context of our Embind-related code is the claim at
<https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>:
"JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262
Edition 12. The new API is called FinalizationRegistry and it still does not
offer any guarantees that the provided finalization callback will be called.
Embind uses this for cleanup if available, but only for smart pointers, and only
as a last resort." However, with the recommended emsdk 2.0.31 my tests did not
show any use of that finalization support. So I wanted to try with the latest
emsdk 3.1.51 instead. But then, linking vcldemo failed with
> wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const
etc., so I gave it a try to rather build against latest Qt6.7, with
> --with-distro=LibreOfficeWASM32
> --disable-qt5
> --enable-qt6
> QT6DIR=...
TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the
recommended setup with emsdk 2.0.31 and the
<https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6
(i.e., my experimental setup with emsdk 3.1.51 and the
<https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5-
vs. Qt6-specific behavior, but also to distinguish between old- vs.
new-Emscripten-specific behavior. Of note:
* The startup code appears to have changed substantially (and required setting
-s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to
build just soffice.js and not the wrapper soffice.html. TODO: This also
required hacking into qt_soffice.html: (1) The command-line arguments
(--norestore, --nologo, --writer, and the exammple.odt; all of which we should
eventually get rid of, anyway). (2) Saving the generated instance as
window.Module (and adapting the embindmaker-generated code, cf. the changes to
static/README.wasm.md).
* There were some symbol clashes between external/argon2 and
libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in
external/argon2.
Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Diffstat (limited to 'RepositoryFixes.mk')
| -rw-r--r-- | RepositoryFixes.mk | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/RepositoryFixes.mk b/RepositoryFixes.mk index 0cbb5ad93e6c..2139b2f823ff 100644 --- a/RepositoryFixes.mk +++ b/RepositoryFixes.mk @@ -35,7 +35,11 @@ ifeq ($(OS),MACOSX) gb_Executable_FILENAMES := $(patsubst soffice_bin:soffice_bin,soffice_bin:soffice,$(gb_Executable_FILENAMES)) else ifeq ($(OS),EMSCRIPTEN) +ifeq ($(ENABLE_QT6),TRUE) +gb_Executable_FILENAMES := $(patsubst soffice_bin:soffice_bin%,soffice_bin:soffice.js,$(gb_Executable_FILENAMES)) +else gb_Executable_FILENAMES := $(patsubst soffice_bin:soffice_bin%,soffice_bin:soffice.html,$(gb_Executable_FILENAMES)) +endif else gb_Executable_FILENAMES := $(patsubst soffice_bin:soffice_bin%,soffice_bin:soffice.bin,$(gb_Executable_FILENAMES)) endif |