summaryrefslogtreecommitdiff
path: root/static/README.wasm.md
AgeCommit message (Collapse)Author
2024-08-29use emrun with explicit "--hostname 127.0.0.1" for testingMoritz Duge
Minor security improvement. See https://github.com/emscripten-core/emscripten/issues/22077 Change-Id: I05d632f6023883672d0e1b2586f53df87dd7d874 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172540 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Reviewed-by: Moritz Duge <moritz.duge@allotropia.de>
2024-08-20More useful to have an EMSCRIPTEN_EXTRA_SOFFICE_PRE_JSStephan Bergmann
...than an EMSCRIPTEN_EXTRA_SOFFICE_POST_JS. That way, we can e.g. set up Module.arguments there. Change-Id: I4990ab6daac2f74326ab2ee9508828f1b79bceb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172154 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-08-20Remove wasm-qt-mandelbrot demoStephan Bergmann
...that had been added with f90c68316c622971706568303a025bbc58351df3 "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>
2024-08-19Fix typoAndrea Gelmini
Change-Id: I3277386244f3a00c2756525829924870e3a3d2bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172030 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-08-19Fix typoAndrea Gelmini
Change-Id: I3fac3dcde5aad559dcbc4c64aeedfd0f6fc1cd6c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172029 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-08-18Emscripten: Document how Qt builds its own freetype, but we link against LO'sStephan Bergmann
Change-Id: I6413c64db3d50f163ee9cc4feda395a54aab3cf2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172012 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-14Emscripten: Run external code on LO's main threadStephan Bergmann
...and not the browser's main thread. Those are different threads now since 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "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 6e6451ce96f47e0ef5e8ecf1750f394ff3fb48e4 "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>
2024-08-12Emscripten: Move the Qt event loop off the JS main threadStephan Bergmann
...so that spawning and joining new threads works now and we no longer need a hardcoded -sPTHREAD_POOL_SIZE of pre-spawned threads (see b84ef4d67eaf9f9fd7fd700ca05339cb0cdff742 "Adapt comphelper::ThreadPool to Emscripten's threading needs"; lets keep MAX_CONCURRENCY capped at 4, at least for now, though). This requires <https://github.com/allotropia/qtbase/commit/167b08844df06e3cea85c98161b26e97442ab242> "Minimal support for Emscripten -sPROXY_TO_PTHREAD=1" and <https://github.com/allotropia/qtbase/commit/c722a25630a5390f18a4d974aa942f6376fcb8e1> "Implement QWasmCursor::changeCursor for Emscripten PROXY_TO_PTHREAD case" (see TODOs there). Change-Id: I8cea827bd7786e3c9fd9401b4b2bef9d3ec00d5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171758 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-08-07I finally understand why we need that hackStephan Bergmann
...that 77129fbb74bcefde4551d494f029169e7c6026e3 "Emscripten: Add hack to prepare for --enable-wasm-exceptions" was puzzled about Change-Id: Iba54a77e3c2a71fe45b97795ca2da0606c3adf41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171594 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-26Add --with-package-format=emscriptenStephan Bergmann
...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
2024-07-25Enable start center in Emscripten buildStephan Bergmann
...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
2024-07-25Fix typoAndrea Gelmini
Change-Id: I465502f90e0ce458f6746efa6e558896f6bea5ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170999 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2024-07-24Document the Emscripten threads issueStephan Bergmann
Change-Id: Ia26b48d46283a9528a665eb5028bd5b9bd0dd953 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170972 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-07-19Drop obsolete "Ideas for an UNO bridge implementation"Stephan Bergmann
Change-Id: Ibf1de9cf8dc18e62b5ee67b31a8e3f3748c3941b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170769 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-07-18Change from Module.intiUno() to Module.uno_init promiseStephan Bergmann
...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>
2024-06-12Embind: Centrally initialize via Module.initUno() in a new uno.jsStephan Bergmann
...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
2024-06-05Clean up example codeStephan Bergmann
* 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>
2024-05-29Emscripten: Unconditional --enable-wasm-exceptionsStephan Bergmann
(...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 77129fbb74bcefde4551d494f029169e7c6026e3 "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>
2024-05-28Emscripten: Add hack to prepare for --enable-wasm-exceptionsStephan Bergmann
(...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
2024-04-19Embind: Consistently represent empty interface references as JS nullStephan Bergmann
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>
2024-04-18Embind: We no longer need interface FromAny ctorStephan Bergmann
...now that we have uno_Any get() since 8428368d79118f1d0e09615c5d2b92065b8838d4 "Improve Embing'ing of UNO Any somewhat" Change-Id: I06572e1ca152117c5c93a1552e50b1399af84780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166244 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-04-16Embind: No need for $queryStephan Bergmann
...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>
2024-04-06Fix typoAndrea Gelmini
Change-Id: I0f6a4ac0910c83d572e2b2e39e8dcea0470517cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165818 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-04-04Improved documentation (Emscripten, Qt5 usage, WASM examples)Moritz Duge
Sentence about Emscripten was probably obsolete since around commit 12a6b57c Change-Id: Ide59154439f8a069c2dbd58420c1c93844790a79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165754 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-04-04Drop spurious .delete() calls from example codeStephan Bergmann
...that had been added there accidentally in 27ceca1996809c0f9390d1e9fb95dc7436ef1acf "Rework the Embind mapping of UNO interfaces" Change-Id: I390e4b694e95d665f7bc3d62b0f7ba2c887041bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165796 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-03-08Redesign Embind UNO Any constructionStephan Bergmann
...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>
2024-03-06Update documented emsdk versionStephan Bergmann
...to what is known-working at allotropia. (Also, emsdk --embedded option is redundant since <https://github.com/emscripten-core/emsdk/commit/3e9f04d467ba300b43fc40dab657c56f39751c96> "Remove support for non-embedded mode".) Change-Id: I7d3f3b72f131301ddc92fcf22503b575f30e7086 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164464 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-29Improve sample code, missing delete()Stephan Bergmann
Change-Id: I26ddbfb8b6742d816290d122d22c3c6c3ceabcc0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164143 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-28Generate slightly more flexible JS init_unoembind_* functionsStephan Bergmann
...that return the "hierarchical object", rather than setting it as a member of the passed-in instance Change-Id: I17ad7dd426114c7979f1ba6edaebe83b43eedfed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164064 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-21Remove stray code from exampleStephan Bergmann
...that had erroneously been added with 27ceca1996809c0f9390d1e9fb95dc7436ef1acf "Rework the Embind mapping of UNO interfaces" Change-Id: I421bf2aa7e9f96ce48b227f6f47058581b64d7b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-03First-class Embind JS support for OUStringStephan Bergmann
Change-Id: Ic178737da802e17f87d0b5b09004a847b0fe91be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162956 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-31embindmaker: Handle enumsStephan Bergmann
Change-Id: I07e068e52df2a838e76f32e691d23a47d7fcfdda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162809 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-30Rework the Embind mapping of UNO interfacesStephan Bergmann
...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>
2024-01-29Experimental support for latest Emscripten (and Qt6)Stephan Bergmann
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>
2024-01-25Let embindmaker also generate a .js file with more natural namesStephan Bergmann
(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>
2023-09-18JavaScript uno bindings for WASM with Embind - first cutSarper Akdemir
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>
2023-02-13Fix typoAndrea Gelmini
Change-Id: I58611c416b2fe198dc847336a592be6683e9b3bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146899 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-13Mention that Emscripten 3.1.30 is known to work for COWASMTor Lillqvist
Change-Id: Id01004121a306dea953b908c32acc7f2c0e6841c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146857 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-02-13Don't overload the word 'module' unnecessarilyTor Lillqvist
Change-Id: I10fb7d16192ddfb0802c976419c00302d4688c4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146856 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-02-06Minor typo fixes and some additional informationTor Lillqvist
Change-Id: Ic0b76ca37dce37f88df62d80495e111c4d50818e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146572 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2023-02-03Fix typoAndrea Gelmini
Change-Id: I48064f95fec07b414bd2addf0d65e2066aa1b42b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146540 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-02Add instructions for when building headless LO core for WASMTor Lillqvist
Change-Id: Ic5fb943f8c26d21d94bafb815963960bdd2f26b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146497 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-12-14Update Qt5 build instructions to use Allotropia's pre-patched repoTor Lillqvist
Change-Id: I4b739e36a008940705b32a2c83757520e2ae1add Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144196 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-03-30Fix typoAndrea Gelmini
Change-Id: Ie50eeb9bcf1670b014ec600b62ef83a4fb27ee59 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132330 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-03-30WASM fix native EH build since Emscripten 3.1.6Jan-Marek Glogowski
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>
2022-01-21Fix typosAndrea Gelmini
Change-Id: I7b3d17431c5acc92ebc593f4f0fae385c944f61b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128727 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-01-20WASM update README.wasm.mdJan-Marek Glogowski
Change-Id: Ic38a7a0637ab007f12a6046655cb7d36e24fae33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128655 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-19WASM merge wasm-qt into static moduleJan-Marek Glogowski
Change-Id: I1ed26685561fd79d26cc0844faa3dfe4c00d439a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128625 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
generated by cgit (git 2.34.1) at 2025-01-09 15:55:12 +0000