Instructions to compile LO on Solaris with gcc

Disclaimer
----------
This is still work in progress
Compiling LO on Solaris with gcc is a work done by Lanedo ( www.lanedo.com )
Any inquiry could be sent to office-solaris@lanedo.com


Prerequisites
-------------

A working Oracle Solaris 11 installation


Installing Dependencies
-----------------------

sudo -s

pkg install git make gcc-45 autoconf autogen automake-110 gnu-m4

pkg install pkg:/system/header@0.5.11-0.175.0.0.0.2.1
pkg install pkg:/developer/gperf@3.0.3-0.175.0.0.0.2.537
pkg install pkg:/developer/parser/bison@2.3-0.175.0.0.0.2.537
pkg install pkg:/developer/lexer/flex@2.5.35-0.175.0.0.0.2.537
pkg install pkg:/developer/documentation-tool/doxygen@1.5.7.1-0.175.0.0.0.2.537


Compiling
---------

CC="gcc" CXX="g++" ./autogen.sh --with-num-cpus=2 --with-max-jobs=4 --without-junit --disable-mozilla --with-system-curl --without-help --disable-cups --without-java --with-system-cairo --with-lang= --enable-gio --disable-gnome-vfs --disable-gstreamer --without-fonts --with-system-dicts --disable-mozilla --without-system-mozilla --disable-xmlsec --with-system-openssl

gmake

Cross-compiling LibreOffice
***************************

Cross-compilation works, to various degree, to the following
platforms: iOS, Android, and Raspbian.

Note that this document has not been updated very often, and not
everything here necessarily is true any more.


General
-------

In GNU Autoconf terminology, "build" is the platform on which you are
running a build of some software and "host" is the platform on which
the software you are building will run. Only in the specific case of
building compilers and other programming tools is the term "target"
used to indicate the platform for which the tools your are building
will produce code. As LibreOffice is not a compiler, the "target" term
should not be used in the context of cross-compilation.

(For a case where all three of "build", "host" and "target" are
different: consider a gcc cross-compiler running on Windows, producing
code for Android, where the cross-compiler itself was built on
Linux. (This is a real case.) An interesting tidbit is that such
configurations are called "Canadian Cross".)

Even though the LibreOffice build mechanism is highly unorthodox, the
configure script takes the normal --build and --host options like any
GNU Autoconf -based configure script. To cross-compile, you basically
need just to specify a suitable --host option and things should work
out nicely. In practice, many details need to be handled. See examples
below.

Note that in the case of LibreOffice, it is uncommon to run the
configure script directly. Normally one uses the autogen.sh script.
The autogen.sh script reads command-line options from file called
autogen.input if it exists. The typical way of working is to keep
the configure parameters in that file and edit it as needed.


What is so hard, then?
----------------------

Despite the fact that the configure script takes normal --build and
--host options, that is just the beginning. It was necessary to
separate tests for "host" and "build" platforms in the configure
script. See the git log for details. And the reasonably "standard"
configure.in is just the top level; when we get down to the actual
makefilery used to build the bits of LibreOffice, it gets much worse.


iOS
***

iOS is the operating system on Apple's mobile devices. Clearly for a
device like the iPad it would not be acceptable to run a normal
LibreOffice application with overlapping windows and mouse-oriented
GUI widgets.

It makes sense to use only a part of LibreOffice's code for iOS. Lots
of the GUI-oriented code should be left out. iOS apps that want to use
the applicable LibreOffice code will handle all their GUI in a
platform-dependent manner. How well it will be possible to do such a
split remains to be seen.

Obviously we want it to be possible to eventually distribute apps
using LibreOffice code through the App Store. Technically, one
important special aspect of iOS is that apps in the App Store are not
allowed to load own dynamic libraries. (System libraries are used in
the form of dynamic libraries, just like on macOS, of which iOS is
a variant.)

Thus all the libraries in LibreOffice that normally are shared
libraries (DLLs on Windows, shared objects (.so) on Linux, dynamic
libraries on macOS (.dylib)) must be built as static archives
instead. This has some interesting consequences for how UNO is
implemented and used.

An iOS app is a "bundle" that contains a single executable. In an app
using LibreOffice code, that executable then contains the necessary
LibreOffice libraries and UNO components statically linked.

The Apple tool-chain for iOS cross-building is available only for OS
X. In order to be able to run and debug an app on an actual device
(and not just the iOS Simulator) you need to be registered in the iOS
Developer Program.

Here is an autogen.input for iOS (device) using Xcode 4.6, on macOS 10.8:

--build=i386-apple-darwin10.7.0
--host=arm-apple-darwin10
--enable-dbgutil
--enable-debug
--enable-werror

For the iOS Simulator, but note that building for the simulator is
broken at the moment (July 2014):

--build=i386-apple-darwin10.7.0
--host=arm-apple-darwin10
--enable-ios-simulator
--enable-dbgutil
--enable-debug
--enable-werror

You will have to install autoconf and automake yourself before running
autogen.sh. They are no longer included in Xcode 4.3 and later (not
even in the add-on "command line tools").

The -mmacosx-version-min=10.7 is necessary when building for the iOS
simulator to avoid clang replacing simple calls to fprintf with calls
to fwrite$UNIX2003 which Xcode then warns that doesn't exist on iOS.


Android
*******

From a technical point of view the core Android OS (the kernel) is
Linux, but everything else is different. Unlike iOS, an Android app
can use shared objects just fine, so that aspect of UNO doesn't need
special handling. Except that there is a silly low limit in the
Android dynamic linker on the number of libraries you can dlopen. This
is a limitation in user-level (but system-provided and not really
replaceable) code, not the kernel.

Thus, just like for iOS, also for Android the LibreOffice libraries
and UNO components are built as static archives. For Android, those
static archives, and any app-specific native code, are linked into one
single app-specific shared library, called liblo-native-code.so.

For the GUI, the same holds as said above for iOS. The GUI layer needs
to be platform-specific, written in Java.

Android cross-compilation work has been done mainly on Linux (openSUSE
in particular). Earlier also cross-compiling from macOS was tried. The
Android cross-compilation tool-chain (the "Native Development Kit", or
NDK) is available for Linux, macOS and Windows, but trying to
cross-compile LibreOffice from Windows will probably drive you insane.

You will also need the Android SDK as full "make" also builds a couple
of Android apps where the upper layer is written in Java.

Use the "android" tool from the SDK to install the SDK Tools, SDK
Platform Tools, the API 15 SDK Platform and the Android Support
Library. If you want to run the Android apps in the emulator, you of
course need an appropriate system image for that.

Here is an autogen.input for Android on ARM when cross-compiling
from Linux:

--enable-dbgutil
--enable-werror
--with-distro=LibreOfficeAndroid
--with-android-sdk=/path/to/android/sdk
--with-android-ndk=/path/to/android/sdk/ndk/version

And here is an (quite old) autogen.input for Android on X86:

--with-android-ndk=/opt/libreoffice/android-ndk-r8b
--with-android-ndk-toolchain-version=4.6
--with-android-sdk=/opt/libreoffice/android-sdk-linux
--build=i586-suse-linux
--enable-ccache
--with-distro=LibreOfficeAndroidX86

A LibreOffice app for Android is being developed progress in the
android/source directory.

To run the app, do "make install" followed by either "make run" or
starting it from Android itself. You most likely want to have an "adb logcat"
running in another window. To debug, run "make debugrun".

NB: If you happen to upgrade to Android SDK Tools 23, and the build (using
'make verbose=t android') fails for you with:

       [dx] UNEXPECTED TOP-LEVEL EXCEPTION:
       [dx] java.io.FileNotFoundException: /local/libreoffice/android-sdk-linux/tools/support/annotations.jar (no such file or directory)

you need to copy the annotations.jar from an older sdk; like

wget 'http://dl-ssl.google.com/android/repository/tools_r22.6.2-linux.zip'
unzip tools_r22.6.2-linux.zip
cp tools/support/annotations.jar <android-sdk-linux>/tools/support/

Raspbian
********

In theory, this should work also for another Linux, it does not need to be Raspbian.
But this cross-compilation work is tested from Debian and openSUSE to Raspbian.

You will need headers, pkg-config files and libraries from a Raspbian
system to build against. Available at
https://dev-www.libreoffice.org/extern/ . Look for the latest
raspbian-root-*.tar.gz . For instance:

$ wget https://dev-www.libreoffice.org/extern/raspbian-root-20140120.tar.gz
$ mkdir raspbian-root
$ cd raspbian-root
$ tar -xf raspbian-root-20140120.tar.gz

You can build cross-compiler yourself or get the executables here:
$ git clone git://github.com/raspberrypi/tools

tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian is known to work.

Then create pkg-config wrapper, something like:
$ cat > pkg-config-wrapper-host << _EOF
#!/bin/sh

if [ "$CROSS_COMPILING" = TRUE ]; then
   SYSROOT=$HOME/lo/raspbian-root
   export PKG_CONFIG_PATH=${SYSROOT}/usr/lib/arm-linux-gnueabihf/pkgconfig:${SYSROOT}/usr/share/pkgconfig
   export PKG_CONFIG_LIBDIR=${SYSROOT}/usr/lib/pkgconfig
   export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
fi

exec pkg-config "\$@"
_EOF
$ chmod +x pkg-config-wrapper-host

This does not work with pkg-config 0.23. 0.26 is known to work.

And you are ready to build with autogen.input similar to:

PKG_CONFIG=<path-to-pkg-config-wrapper-host>
CC=<path-to-arm-linux-gnueabihf-gcc> --sysroot=<path-to-raspbian_rootfs>
CXX=<path-to-arm-linux-gnueabihf-g++> --sysroot=<path-to-raspbian_rootfs>
--build=x86_64-unknown-linux-gnu
--host=arm-unknown-linux-gnueabihf
--disable-sdk
--enable-python=system
PYTHON_CFLAGS=-I<path-to-raspbian_rootfs>/usr/include/python2.7
PYTHON_LIBS=-lpython2.7
--with-java
JAVAINC=-I<path-to-raspbian_rootfs>/usr/lib/jvm/java-6-openjdk-armhf/include
--with-system-cairo
--with-system-cppunit
--with-system-icu
--with-system-neon
--with-system-nss
--with-system-openldap
--with-system-openssl
--with-system-redland

Finally, when you are ready to run the binaries in Raspbian,
you may need to get more system libraries, who knows.
$ sudo apt-get install libreoffice # or similar
That installs libreoffice too, which you don't need because you have
just built one, but I don't know how to avoid it easily.

# LibreOffice
[![Coverity Scan Build Status](https://scan.coverity.com/projects/211/badge.svg)](https://scan.coverity.com/projects/211) [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/307/badge)](https://bestpractices.coreinfrastructure.org/projects/307) [![Translation status](https://weblate.documentfoundation.org/widgets/libo_ui-master/-/svg-badge.svg)](https://weblate.documentfoundation.org/engage/libo_ui-master/?utm_source=widget)

<img align="right" width="150" height="200" src="https://opensource.org/files/OSIApproved.png">

LibreOffice is an integrated office suite based on copyleft licenses
and compatible with most document formats and standards. Libreoffice
is backed by The Document Foundation, which represents a large
independent community of enterprises, developers and other volunteers
moved by the common goal of bringing to the market the best software
for personal productivity. LibreOffice is open source, and free to
download, use and distribute.

A quick overview of the LibreOffice code structure.

## Overview

You can develop for LibreOffice in one of two ways, one
recommended and one much less so. First the somewhat less recommended
way: it is possible to use the SDK to develop an extension,
for which you can read the API docs [here](https://api.libreoffice.org/)
and [here](https://wiki.openoffice.org/wiki/Documentation/DevGuide).
This re-uses the (extremely generic) UNO APIs that are also used by
macro scripting in StarBasic.

The best way to add a generally useful feature to LibreOffice
is to work on the code base however. Overall this way makes it easier
to compile and build your code, it avoids any arbitrary limitations of
our scripting APIs, and in general is far more simple and intuitive -
if you are a reasonably able C++ programmer.

## The Build Chain and Runtime Baselines

These are the current minimal operating system and compiler versions to
run and compile LibreOffice, also used by the TDF builds:

* Windows:
    * Runtime: Windows 7
    * Build: Cygwin + Visual Studio 2019 version 16.5
* macOS:
    * Runtime: 10.10
    * Build: 10.14.4 + Xcode 11.3
* Linux:
    * Runtime: RHEL 7 or CentOS 7
    * Build: either GCC 7.0.0; or Clang 5.0.2 with libstdc++ 7.3.0
* iOS (only for LibreOfficeKit):
    * Runtime: 11.4 (only support for newer i devices == 64 bit)
    * Build: Xcode 9.3 and iPhone SDK 11.4
* Android:
    * Build: NDK r19c and SDK 22.6.2
* Emscripten / WASM:
    * Runtime: a browser with SharedMemory support (threads + atomics)
    * Build: Qt 5.15 with Qt supported Emscripten 1.39.8
    * See README.wasm

If you want to use Clang with the LibreOffice compiler plugins, the minimal
version of Clang is 5.0.2. Since Xcode doesn't provide the compiler plugin
headers, you have to compile your own Clang to use them on macOS.

You can find the TDF configure switches in the `distro-configs/` directory.

To setup your initial build environment on Windows and macOS, we provide
the LibreOffice Development Environment
([LODE](https://wiki.documentfoundation.org/Development/lode)) scripts.

For more information see the build instructions for your platform in the
[TDF wiki](https://wiki.documentfoundation.org/Development).

## The Important Bits of Code

Each module should have a `README.md` file inside it which has some
degree of documentation for that module; patches are most welcome to
improve those. We have those turned into a web page here:

<https://docs.libreoffice.org/>

However, there are two hundred modules, many of them of only
peripheral interest for a specialist audience. So - where is the
good stuff, the code that is most useful. Here is a quick overview of
the most important ones:

Module    | Description
----------|-------------------------------------------------
[sal/](sal)             | this provides a simple System Abstraction Layer
[tools/](tools)         | this provides basic internal types: `Rectangle`, `Color` etc.
[vcl/](vcl)             | this is the widget toolkit library and one rendering abstraction
[framework/](framework) | UNO framework, responsible for building toolbars, menus, status bars, and the chrome around the document using widgets from VCL, and XML descriptions from `/uiconfig/` files
[sfx2/](sfx2)           | legacy core framework used by Writer/Calc/Draw: document model / load/save / signals for actions etc.
[svx/](svx)             | drawing model related helper code, including much of Draw/Impress

Then applications

Module    | Description
----------|-------------------------------------------------
[desktop/](desktop)  | this is where the `main()` for the application lives, init / bootstrap. the name dates back to an ancient StarOffice that also drew a desktop
[sw/](sw/)           | Writer
[sc/](sc/)           | Calc
[sd/](sd/)           | Draw / Impress

There are several other libraries that are helpful from a graphical perspective:

Module    | Description
----------|-------------------------------------------------
[basegfx/](basegfx)  | algorithms and data-types for graphics as used in the canvas
[canvas/](canvas)   | new (UNO) canvas rendering model with various backends
[cppcanvas/](cppcanvas) | C++ helper classes for using the UNO canvas
[drawinglayer/](drawinglayer) | View code to render drawable objects and break them down into primitives we can render more easily.

## Rules for #include Directives (C/C++)

Use the `"..."` form if and only if the included file is found next to the
including file. Otherwise, use the `<...>` form. (For further details, see the
mail [Re: C[++]: Normalizing include syntax ("" vs
<>)](https://lists.freedesktop.org/archives/libreoffice/2017-November/078778.html).)

The UNO API include files should consistently use double quotes, for the
benefit of external users of this API.

`loplugin:includeform (compilerplugins/clang/includeform.cxx)` enforces these rules.


## Finding Out More

Beyond this, you can read the `README.md` files, send us patches, ask
on the mailing list libreoffice@lists.freedesktop.org (no subscription
required) or poke people on IRC `#libreoffice-dev` on irc.libera.chat -
we're a friendly and generally helpful mob. We know the code can be
hard to get into at first, and so there are no silly questions.

= Status =

$ make
$ emrun --serve_after_close instdir/program/ui-previewer.html

The ui-previewer "binary" will "crash" with memory alignment problems.

You can run the WASM mandelbrot Qt example, if you copy its HTML
and the qtloader.js from the Qt's example folder after build with:

$ emrun --serve_after_close workdir/LinkTarget/Executable/mandelbrot.html

REMINDER: always start new tabs in the browser, reload might fail / cache!


= Setup for the LO WASM build (with Qt) =

We're using Qt 5.15 with the officially supported emscripten v1.39.8.
But there are several potential problems with threads and exceptions, so this will likely
change later to a newer emscripten.

Qt WASM is not yet used with LO, just if you're wondering!

 ++ See below under Docker build for another build option ++

== Setup emscripten ==

https://emscripten.org/docs/getting_started/index.html

git clone https://github.com/emscripten-core/emsdk.git
./emsdk install 1.39.8
./emsdk activate --embedded 1.39.8

Example bashrc scriptlet:

EMSDK_ENV=$HOME/Development/libreoffice/git_emsdk/emsdk_env.sh
[ -f "$EMSDK_ENV" ] && \. "$EMSDK_ENV" 1>/dev/null 2>&1


== Setup Qt ==

https://doc.qt.io/qt-5/wasm.html

I originally build the Qt 5.15 branch, but probably better to build a tag like v5.15.2.

So:

git clone https://github.com/qt/qt5.git
cd qt5
git checkout v5.15.2
./init-repository
./configure -xplatform wasm-emscripten -feature-thread -compile-examples -prefix $PWD/qtbase
make -j<CORES> module-qtbase module-qtdeclarative

Building with examples will break with some of them, but at that point Qt already works.

At some point Qt configure failed for me with:
"Checking for target architecture... Project ERROR: target architecture detection binary not found."

What seems to have fixed this was to run "emsdk activate 1.39.8" again.

Current Qt fails to start the demo webserver: https://bugreports.qt.io/browse/QTCREATORBUG-24072
Use "emrun --serve_after_close" to run Qt WASM demos

Enabling multi-thread support in Firefox is a bit of work with older versions:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1477743#c7
- https://wiki.qt.io/Qt_for_WebAssembly#Multithreading_Support
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer


== Setup LO ==

autogen.sh is patched to use emconfigure. That basically sets various environment vars,
especially EMMAKEN_JUST_CONFIGURE, which will create the correct output file names, checked by
configure (a.out).

There's a distro config for WASM (work in progress), that gets your
defaults right (and currently disables a ton of 3rd party stuff which
is not essential).

Recommended configure setup is thusly:

# grab defaults
--with-distro=LibreOfficeWASM32

# local config
QT5DIR=/dir/of/git_qt5/qtbase

# if you want to use ccache on both sides of the build
--with-build-platform-configure-options=--enable-ccache
--enable-ccache


== Using Docker to cross-build with emscripten ==

If you prefer a controlled environment (sadly emsdk install/activate
is _not_ stable over time, as e.g. nodejs versions evolve), that is
easy to replicate across different machines - consider the docker
images we're providing.

Config/setup file see
https://git.libreoffice.org/lode/+/ccb36979563635b51215477455953252c99ec013

Run

 docker-compose build

in the lode/docker dir to get the container prepared. Run

 PARALLELISM=4 BUILD_OPTIONS= BUILD_TARGET=build docker-compose run --rm -e PARALLELISM -e BUILD_TARGET -e BUILD_OPTIONS builder

to perform an actual srcdir != builddir build; the container mounts
checked-out git repo and output dir via docker-compose.yml (so make
sure the path names there match your setup):

The lode setup expects, inside the lode/docker subdir, the following directories:

- core (git checkout)
- workdir (the output dir - gets written into)
- cache (ccache tree)
- tarballs (external project tarballs gets written and cached there)


= Ideas for an UNO bridge implementation =

My post to Discord #emscripten: "I'm looking for a way to do an abstract call
from one WASM C++ object to another WASM C++ object, so like FFI / WebIDL,
just within WASM. All my code is C++ and normally I have bridge code, with
assembler to implement the function call /RTTI and exception semantics of the
specified platform. Code is at
https://cgit.freedesktop.org/libreoffice/core/tree/bridges/source/cpp_uno.
I've read a bit about call_indirect and stuff, but I don't have yet a good
idea, how I could implement this (and  there is an initial feature/wasm branch
for the interested). I probably need some fixed lookup table, like on iOS,
because AFAIK you can't dynamically generate code in WASM. So any pointers or
ideas for an implementation? I can disassemble some minimalistic WASM example
and read clang code for WASM_EmscriptenInvoke, but if there were some
standalone code or documentation I'm missing, that would be nice to know."

We basically would go the same way then the other backends. Write the bridge in
C++, which is probably largely boilerplate code, but the function call in WAT
(https://github.com/WebAssembly/wabt) based on the LLVM WASM calling
conventions in WASM_EmscriptenInvoke. I didn't get a reply to that question for
hours. Maybe I'll open an Emscripten issue, if we really have to implement
this.

WASM dynamic dispatch: https://fitzgeraldnick.com/2018/04/26/how-does-dynamic-dispatch-work-in-wasm.html


= Workaround for eventual clang WASM compiler bug =

sc/source/core/data/attarray.cxx:378:44: error: call to member function 'erase' is ambiguous
                        aNewCondFormatData.erase(nIndex);
                        ~~~~~~~~~~~~~~~~~~~^~~~~
include/o3tl/sorted_vector.hxx:86:15: note: candidate function
    size_type erase( const Value& x )
              ^
include/o3tl/sorted_vector.hxx:97:10: note: candidate function
    void erase( size_t index )

This is currently patched by using x.erase(x.begin() + nIndex).

There shouldn't be an ambiguity, because of "[WebAssembly] Change size_t to `unsigned long`."
(https://reviews.llvm.org/rGdf07a35912d78781ed6a62a7c032bfef5085a4f5#change-IrS9f6jH6PFq),
from "Jul 23 2018" which pre-dates the emscripten tag 1.39.8 from 02/14/2020 by ~1.5y.


= Tools for problem diagnosis =

* nm -s should list the symbols in the archive, based on the index generated by ranlib.
  If you get linking errors that archive has no index.


= Emscripten filesystem access with threads =

This is closed, but not really fixed IMHO: https://github.com/emscripten-core/emscripten/issues/3922


= Dynamic libraries / modules in emscripten =

There is a good summary in https://bugreports.qt.io/browse/QTBUG-63925

Summary: you can't use modules and threads.

This is mentioned at the end of: https://github.com/emscripten-core/emscripten/wiki/Linking
The usage of MAIN_MODULE and SIDE_MODULE has other problems, a major one IMHO is symbol resolution at runtime only.
So this works really more like plugins in the sense of symbol resolution without dependencies / rpath.

There is some clang-level dynamic-linking in progress (WASM dlload). The following link is already a bit old,
but I found it a god summary of problems to expect:
https://iandouglasscott.com/2019/07/18/experimenting-with-webassembly-dynamic-linking-with-clang/


= Mixed information, links, problems, TODO =

More info on Qt WASM emscripten pthreads: https://wiki.qt.io/Qt_for_WebAssembly#Multithreading_Support

WASM needs -pthread at compile, not just link time for atomics support. Alternatively you can provide
-s USE_PTHREADS=1, but both don't seem to work reliable, so best provide both.
https://github.com/emscripten-core/emscripten/issues/10370

The output file must have the prefix .o, otherwise the WASM files will get a
node.js shebang (!) and ranlib won't be able to index the library (link errors).

Qt with threads has further memory limit. From Qt configure:
Project MESSAGE: Setting PTHREAD_POOL_SIZE to 4
Project MESSAGE: Setting TOTAL_MEMORY to 1GB

You can actually allocate 4GB: https://bugzilla.mozilla.org/show_bug.cgi?id=1392234

LO uses a nested event loop to run dialogs in general, but that won't work, because you can't drive
the browser event loop. like VCL does with the system event loop in the various VCL backends.
Changing this will need some major work (basically dropping Application::Execute).

But with the know problems with exceptions and threads, this might change:
- https://github.com/emscripten-core/emscripten/pull/11518
- https://github.com/emscripten-core/emscripten/issues/11503
- https://github.com/emscripten-core/emscripten/issues/11233
- https://github.com/emscripten-core/emscripten/issues/12035

We're also using emconfigure at the moment. Originally I patched emscripten, because it
wouldn't create the correct a.out file for C++ configure tests. Later I found that
the emconfigure sets EMMAKEN_JUST_CONFIGURE to work around the problem.

ICU bug: https://github.com/emscripten-core/emscripten/issues/10129
Alternative, probably: https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Intl

There is a wasm64, but that still uses 32bit pointers!

Old outdated docs: https://wiki.documentfoundation.org/Development/Emscripten
Reverted patch: https://cgit.freedesktop.org/libreoffice/core/commit/?id=0e21f6619c72f1e17a7b0a52b6317810973d8a3e

Generally https://emscripten.org/docs/porting:
- https://emscripten.org/docs/porting/guidelines/api_limitations.html#api-limitations
- https://emscripten.org/docs/porting/files/file_systems_overview.html#file-system-overview
- https://emscripten.org/docs/porting/pthreads.html
- https://emscripten.org/docs/porting/emscripten-runtime-environment.html

This will be interesting: https://emscripten.org/docs/getting_started/FAQ.html#how-do-i-run-an-event-loop

This didn't help much yet: https://github.com/emscripten-ports

Emscripten supports standalone WASI binaries: https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone

https://www.qt.io/qt-examples-for-webassembly
http://qtandeverything.blogspot.com/2017/06/qt-for-web-assembly.html
http://qtandeverything.blogspot.com/2020/
https://emscripten.org/docs/api_reference/Filesystem-API.html
https://discuss.python.org/t/add-a-webassembly-wasm-runtime/3957/12
http://git.savannah.gnu.org/cgit/config.git
https://webassembly.org/specs/
https://developer.chrome.com/docs/native-client/
https://emscripten.org/docs/getting_started/downloads.html
https://github.com/openpgpjs/openpgpjs/blob/master/README.md#getting-started
https://developer.mozilla.org/en-US/docs/WebAssembly/Using_the_JavaScript_API
https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md
https://www.ip6.li/de/security/x.509_kochbuch/openssl-fuer-webassembly-compilieren
https://emscripten.org/docs/introducing_emscripten/about_emscripten.html#about-emscripten-porting-code
https://emscripten.org/docs/compiling/Building-Projects.html