Support de compilation croisée Emscripten dans LibreOffice/core

Périmètre du dépôt et restrictions énoncées

Le dépôt est un miroir en lecture seule du code central de LibreOffice. Sa description indique que les pull requests ne sont pas acceptées, que les contributions doivent passer par Gerrit et qu'il ne faut pas télécharger de zip mais utiliser les bundles sur dev-www.libreoffice.org. Le README porte spécifiquement sur la compilation de LibreOffice en WebAssembly avec la chaîne d'outils Emscripten. Il décrit deux objectifs : produire un binaire WASM de LibreOffice avec une interface Qt5, ou compiler uniquement le noyau (« LibreOffice Technology ») sans interface pour l'utiliser dans un autre logiciel qui fournit l'interface, comme Collabora Online compilé en WASM. Le README ne donne ni historique du dépôt ni vue d'ensemble du code.

Deux cibles de compilation

Le README traite les deux cibles séparément. La première, qui était la raison initiale du port WASM, produit une compilation Writer uniquement avec Qt5. Il fournit des commandes emrun pour lancer qt_soffice.html ou qt_vcldemo.html depuis la sortie de compilation. La deuxième cible est une compilation sans interface, documentée vers la fin du README, destinée à intégrer le noyau LibreOffice dans un autre produit. Elle ne nécessite pas Qt ni de dépendances au-delà de celles normalement téléchargées et compilées pour LibreOffice. Un exemple d'autogen.input est donné avec des options comme --disable-gui et --with-wasm-module=writer.

Versions de la chaîne d'outils et configuration de l'environnement

La compilation basée sur Qt utilise Qt 5.15.2 et Emscripten 4.0.10. Le README avertit qu'Emscripten évolue rapidement et que d'autres versions causent souvent des problèmes arbitraires. Il fournit des commandes pour installer emsdk 4.0.10. Pour Qt, il recommande un fork maintenu par allotropia car Qt 5.15 LTS n'est pas maintenu publiquement et Qt WASM a plusieurs bogues. Il mentionne aussi une limitation avec -fwasm-exceptions et simulate_infinite_loop, et renvoie à un hack dans desktop/source/app/sofficemain.cxx. Pour la compilation sans interface, le README indique qu'Emscripten 3.1.30 est connu pour fonctionner, tandis que le travail LO+Qt5 a utilisé 2.0.31.

Configuration de compilation et déploiement

Pour la compilation Qt, configurer avec --with-package-format=emscripten remplit workdir/installation/LibreOffice/emscripten avec les fichiers pertinents d'instdir. autogen.sh est modifié pour utiliser emconfigure, et la configuration de distribution recommandée est --with-distro=LibreOfficeWASM32. Le déploiement est décrit comme une commande tar qui empaquette les fichiers soffice.* et qt*, et le serveur HTTP doit envoyer les en-têtes Cross-Origin-Opener-Policy: same-origin et Cross-Origin-Embedder-Policy: require-corp. Le README décrit aussi une compilation croisée Docker avec les images du dépôt lode, pour un environnement contrôlé et reproductible car l'installation d'emsdk n'est pas stable dans le temps.

Liaisons UNO et interaction JavaScript

Le README documente une implémentation initiale grossière des liaisons UNO avec Embind, notant que beaucoup de parties ne sont pas implémentées et qu'il pourrait y avoir des fuites mémoire. Il donne deux exemples JavaScript : l'un insère une chaîne au début du document Writer, l'autre change chaque paragraphe en une couleur aléatoire. Les deux utilisent Module.uno_init.then pour initialiser puis appellent des API UNO. Le README précise que ces exemples doivent être saisis dans la console du premier thread web worker, le thread principal LO, car la compilation utilise -sPROXY_TO_PTHREAD. Alternativement, un script peut être placé à côté de qt_soffice.html et chargé via Module.uno_scripts pendant la compilation.

Limitations connues et contournements

Le README consigne plusieurs restrictions d'Emscripten et de Qt. Il indique que les modules et les threads ne peuvent pas être utilisés ensemble, et que MAIN_MODULE/SIDE_MODULE ont des problèmes comme la résolution de symboles uniquement à l'exécution. L'émulation pthread d'Emscripten exige que la boucle d'événements du thread principal JS réponde rapidement, mais la boucle d'événements Qt5 tourne sur ce thread, d'où le besoin de workers pré-créés via -sPTHREAD_POOL_SIZE. Le README explique aussi que LO utilise normalement une boucle d'événements imbriquée pour les dialogues, mais celle-ci ne peut pas piloter la boucle du navigateur et nécessiterait d'abandonner Application::Execute. D'autres points : une limite mémoire par défaut de 1 Go dans Qt (4 Go possibles), un bogue ICU et wasm64 utilisant encore des pointeurs 32 bits.

Outils de diagnostic et liens supplémentaires

Pour le diagnostic, le README suggère d'utiliser nm -s pour lister les symboles d'une archive selon l'index généré par ranlib, car des erreurs de liaison peuvent signifier que l'archive n'a pas d'index. Pour le débogage, il décrit l'utilisation des informations DWARF intégrées par LLVM dans WASM avec Chrome, nécessitant une fonctionnalité expérimentale et une extension ; la compilation de débogage sépare DWARF dans un fichier .debug.wasm supplémentaire. Le README se termine par une longue liste de liens externes sur la documentation Qt WASM, le système de fichiers Emscripten, pthreads, les boucles d'événements et d'anciennes documentations obsolètes, sans évaluer lui-même ces ressources.

Conclusion éditoriale

Le README décrit la compilation sans interface comme « that's all » et précise que soffice.wasm n'est produit que comme effet secondaire ; le besoin réel est soffice.data, qui contient le système de fichiers en mémoire utilisé par le code central de LibreOffice Technology.

Sources officielles

1. Official documentation
2. Official README
3. Project repository