...as building against emsdk 3.1.46 now started to fail with
> /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_wasm/svx/source/svdraw/svdmrkv.cxx:1231:78: error: no member named 'view' in 'std::stringstream'
> 1231 | handleArrayStr = OString::Concat(", \"handles\":") + aStream.view();
> | ~~~~~~~ ^
> /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_wasm/svx/source/svdraw/svdmrkv.cxx:1236:86: error: no member named 'view' in 'std::stringstream'
> 1236 | handleArrayStr += OString::Concat(", \"GluePoints\":") + aStream.view();
> | ~~~~~~~ ^
(<https://ci.libreoffice.org//job/lo_daily_tb_linux_wasm/1251/>) after
47da2ff20e "Avoid some std::string creation".
So just bump to the most recent emsdk version that works out of the box.
Anything newer than emsdk 4.0.10 (like the current emsdk 4.0.20) would currently
fail for us with the issue described at
<https://gerrit.libreoffice.org/c/core/+/188465> "Emscripten: Adapt to internal
emscripten/val.h change in Emscripten 4.0.11", though, so stick with emsdk
4.0.10 for now.
Change-Id: I540569e43454c222424895b1e552b8b07d1d5066
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194331
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Option is for WASM only, so shouldn't be named --with-main-module.
Also the option's default value changed since it was introduced, so the
documentation became outdated. See commits:
fe678ffc6f Emscripten: No need to pass --with-main-module into build configure
437b4d802c Fix default value of Emscripten --with-main-module
8aef8c3a14 Make it possible to run either Writer or Calc in the same Emscripten thing
97ee126d69 WASM add Calc as optional build result, make it build & run
Change-Id: I29aeeb9a840ec07e46cbf153c535b3fca9d88cd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182798
Tested-by: Jenkins
Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
...and just unused dummies since 3.1.58, so don't install them for >= 3.1.58,
even if the dummies would still be available for < 3.1.68
Change-Id: Ida55be2fa3b75982bfd764b7b2676e63c092fe79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175822
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...that had been added with f90c68316c "WASM: add
Emscripten demo application". Whatever the original intention, it has probably
served its purpose by now---and now only negatively impacts (re-)build times.
Change-Id: I2bda8d12b91e741c4d0f7d3f02597e0e9505a73a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and not the browser's main thread. Those are different threads now since
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread". Running `Module.uno_init.then` on the browser's main
thread would never trigger, as that promise is only resolved on LO's main
thread.
When external code was included in soffice.js via
EMSCRIPTEN_EXTRA_SOFFICE_POST_JS, that didn't make a difference: Emscripten
effectively replicates that code to all the worker threads, so whatever worker
thread resolved the Module.uno_init promise (i.e., the LO main thread) had the
external code available and ran it. But when external code was included
directly in some HTML file (which "manually" provides a canvas and loads
soffice.js, not relying on the qt_soffice.html convenience functionality), it
was available in the browser's main thread but not in LO's main thread. For
that use case, introduce a new Module.uno_scripts array that can be set up in
the HTML file to contain an array of URLs (represented as strings) of scripts to
load into LO's main thread.
(Alternatively, running external code on the browser's main thread rather than
on LO's main thread could be more ideal in the sense that the external code
would then have access to the browser's document object. But, for one, it would
be less ideal in the sense that we would then potentially again execute LO code
(which we call into from the external code via UNO) on the browser's main
thread, which would bring back the issues that
6e6451ce96 "Emscripten: Move the Qt event loop off
the JS main thread" solved. And, for another, when I experimentally tried it
out, it caused massive Qt threading issues, so I quickly gave up again.)
Change-Id: If01a7859751706f168e93ccac75758ae5ce17cd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171870
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to have $(WORKDIR)/installation/LibreOffice/emscripten populated with just
the relevant files from $(INSTDIR). (This doesn't reuse the complicated
CustomTarget_instsetoo_native/install used for other PKGFORMATs; as a special
case, it uses a much simpler CustomTarget_instsetoo_native/emscripten-install.)
Change-Id: I9c7509aadbc0e6e49ec95bf51c748c2ff9f778b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171066
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...and let it open with that instead of with a hard-coded example.odt. (But
keep that example.odt in CustomTarget,static_emscripten_fs_image and adapt the
example code in static/README.wasm.md to explicitly load it now.)
Change-Id: Ie43e3795e44542acba5a8e755f65acc56fa753f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171019
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...that is resolved from within C++ Desktop::InitApplicationServiceManager once
UNO is fully initialized, so client code can trigger on
Module.uno_init.then(...)
Change-Id: I2d4c542d9729d09f434502e3f966e9ee474e926c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...so that the unoObject function can be moved there too (so that other code
outside embindtest.js can reuse it)
Change-Id: Id3edb7cede56321db29ba435f221cb7702a3513c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168700
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
* Consistently use `const` to introduce variable bindings.
* Don't rely on `xText` from the first example in the second one.
* No (more) need to query for base interfaces.
* No (more) need to delete interface references.
* Add a missing delete of Any `next`.
* Remove a redundant empty line.
* Adapt to our 100 character line width.
Change-Id: Ie116021a4b0cc6d88c6204e7ea5147a837c251f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168405
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(...which will be beneficial, in turn, to implement exception handling in the
work-in-progress bridges/source/cpp_uno/gcc3_wasm UNO bridge).
As per
<https://developer.mozilla.org/en-US/docs/WebAssembly#browser_compatibility>,
Wasm exceptions appear to be supported by most if not all relevant engines by
now.
* Lets see whether the "Note that to really use WASM exceptions everywhere" for
external libraries in solenv/gbuild/platform/EMSCRIPTEN_INTEL_GCC.mk does have
any practical consequences (but ignoring it for now).
* This change depends on the preceding 77129fbb74
"Emscripten: Add hack to prepare for --enable-wasm-exceptions" to work around
the issue that was mentioned in static/README.wasm.md.
* In unotest/source/embindtest/embindtest.js, getExceptionMessage started to
work now, no longer exhibiting the RuntimeError that had been documented there
for non-Wasm-based exceptions.
Change-Id: Ifa2165b62208cc927844684911ddf21a4a2b624f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(...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.bergmann@allotropia.de>
Tested-by: Jenkins
The existing code had two issues: For one, e.g. calling a function that
returned a null interface reference mapped that to JS null, while querying an
object for a non-supported interface via `new css.uno.X...(y)` mapped that to
an "empty" JS object instead. (So checking for a non-null reference needed to
be done as either `x !=== null` or as `x.is()`, depending on context.) And for
another, while calling $is() on a non-"empty" object worked fine, it failed on
such an "empty" object (as the Embind internals of that object lacked the $$
property).
So change the querying mechanism from the `new css.uno.X...(y)` constructor to a
`css.uno.X....query(y)` function call syntax, which now returns JS null when
querying for a non-supported interface. (And drop the broken $is method.)
Change-Id: I8fa488ab2892423f2a461d9b72db47e1d4df3b8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166255
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to "upcast" from css::uno::Reference<T> to base
css::uno::Reference<css::uno::XInterface>. My understanding now is that due to
the sharing_policy::INTRUSIVE we specify for
emscripten::smart_ptr_trait<css::uno::Reference<T>>
(include/static/unoembindhelpers/PrimaryBindings.hxx), Embind can internally
"upcast" from a css::uno::Reference<T> to a base
css::uno::Reference<css::uno::XInterface> by just treating the encapsulated raw
pointer of type T* as a raw pointer of type css::uno::XInterface* (see the use
of that sharingPolicy in genericPointerToWireType in Emscripten's
src/embind/embind.js; though documentation of that Embind sharing_policy is
rather poor).
Change-Id: I6ed60a9c94af6aba6fc6119bf644da7f507a997f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...taking a full UNO Type instead of just a UNO Type class (so that it will be
able to construct Any containing sequence, enum, struct, exception, and
interface, in later steps); moving the Type argument first (as that looks more
natural), and renaming from Any to uno_Any (in line with the other uno_Type,
uno_Sequence_..., etc.)
Change-Id: I154681c4b9187f5f5d037d503652fe7bcd41adcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164593
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to make use of the automatic finalization clean-up of smart pointers
available with recent versions of Embind (so that explicitly calling delete() on
them should largely be optional now). See the changes to static/README.wasm.md
for how code should look like now. (The Module.uno_Reference.FromAny dummy
argument for the interface constructor converting from an Any is only necessary
to distinguish it from the other constructor, as otherwise Embind complains
because: "Overload resolution is currently only performed using the parameter
count, not actual type info!")
Change-Id: Ia8a8c12e38af1093948bf8a20ecd31aa6591e912
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162697
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
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>
(i.e., Module.unoembind_uno.com.sun.star... vs. Module.com$sun$star$..., and see
the updated examples in static/README.wasm.md for further shortening that to
just css...)
Change-Id: I6dc079caa8c93a4042a6a8aa2d8fcc8f76bf80f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162580
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
A rough implementation of uno bindings for LOWA using embind.
Adds new parameter '-W' to cppumaker to generate _embind.cxx
files alongside .hdl & .hpp.
For usage examples see static/README.wasm.md
Change-Id: Iee5d05e37bfba8e101c08212b15c05f7f2fa6c33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156273
Tested-by: Jenkins
Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
Aditya Lohuni