#834 Add WASI platform support

[PuQ]

For those interested in running gnuplot on WASI, there is an experimental patch (based on 6.1 [444208]) to make gnuplot work on WASI.

Non-goal:

• Functions depending on external libraries
• Readline support (WASI does not support termio)

Build dependencies:

• Clang 20.1+
• wasi-libc, can be installed with package managers
• wasi-compiler-rt, can be installed with package managers

Build (wasi-sysroot path may be different from this one):

./prepare
PKG_CONFIG_LIBDIR=/usr/share/wasi-sysroot/lib CC=clang ./configure --host=wasm32-wasi --with-wasi-sysroot=/usr/share/wasi-sysroot
cd src
make timestamp.h binonly

Test with Wasmtime:

wasmtime -Wexceptions gnuplot.wasm -V
wasmtime -Wexceptions gnuplot.wasm -e 'set term dumb; p sin(x), cos(x)'
wasmtime -Wexceptions --env HOME=/tmp --dir /tmp::/tmp gnuplot.wasm

[Ethan Merritt]

I am potentially very interested in this, but I am very much not up to speed on the wasm ecosystem. Furthermore so far as I can tell, the linux systems I normally work on do not provide any of the relevant support packages, so I am at least one or two major steps away from being able to try this out. Maybe you can provide some guidance...

• Would it be more reasonable to work from the GitHub repository code and build it up the clang/wasm/wasi development tools from scratch or to start by installing a different linux distro that offer relevant pre-built packages? I am not a fan of Fedora, but maybe Arch or Mint?
• There was previous work to build gnuplot for emscripten, but I am unclear on the relationship between emscripten and wasm/wasi.. Is there any connection?
• Maybe you could give a birds-eye summary of the use cases you see for gnuplot + wasi. In particular I am wondering how much of the existing terminal output code is relevant - would typical graphics output go via qt or kitty or svg or what? In the earlier proof-of-principle emscripten work the output went to svg, but it was not very well integrated.
• What exactly is the issue you mention with termio? I gather that wasi does not provide an emulation for the termios library, but gnuplot's builtin readline should fall back to using ioctls instead. Does that not work either?
• Could you attach the output from the configure script from your test run? I'd like to see how much of the code above a bare minimum was pulled in and therefore known to build successfully (run performance not guaranteed of course).

[PuQ]

wasi-sdk would be a good start, rather than installing another distro. It is a prebuilt bundle providing latest clang, wasi-libc and wasi-compiler-rt.

I don't have much experience in Emscripten, but from what I know, Emscripten and WASI are two platforms (wasm32-emscripten and wasm32-wasi for compilers), providing different libc for Wasm. Wasm is more like a common architecture.

WASI is also a set of system APIs designed to make more apps run anywhere including browsers/machines/servers. It provides POSIX-like system interfaces for Wasm to access OS (for gnuplot, that would be reading and writing local files, getting time and environment variables). Wasm apps call these APIs inside the WASI runtime, which are then executed by the runtime. In most cases, Wasm binaries built by Emscripten (usually with js files) are mainly run inside browsers, however, Emscripten also uses WASI APIs outside browsers (without js files).

Currently, WASI has three independent versions (0.1, 0.2 and 0.3). The widely used one is WASI 0.1 (more commonly known as wasip1, WASI Preview 1). Most Wasm runtimes also support WASI 0.1.

GUI terminals like qt and wxt, depending on lots of system libraries and complex syscalls, are almost impossible for WASI. Many raster terminals require system fonts via fontconfig, they may work, but I have never tried building fontconfig into gnuplot on WASI. I think svg would still be the best terminal on WASI as it is zero-dependency and vector-based.

WASI only has limited ioctl support, without terminal-related ioctls. In other words, there is no terminal API on WASI, and wasi-libc is just a C wrapper for these underlying WASI APIs. Since gnuplot lacks readline support on WASI, I think it would be well-suited as a plugin/extension for other software (like a plugin for Typst, it can be run on different platforms, including browsers, but using the same Wasm binary), maybe also a Web API backend.

I've made an asciinema recording showing how to build gnuplot using wasi-sdk, and here is a link to view it online.

[Ethan Merritt]

Now that I've looked at the patch, I wonder if 99% of it could be respun as "optional support for using memory-backed scratch space viafmemopen and open_memstream rather than using tempfiles. That seems like a perfectly reasonable option in any case, and it might then simplify WASI support into something like "you must select this option during configuration". Do I have that right?

Thanks for the session output video. That gives me an idea of what you ended up with and what is missing.

As to terminal output modes -

I think Qt explicitly supports WASM: (https://doc.qt.io/qt-6/wasm.html)
I'm still trying to understand exactly where WASI fits in on top of that, but I would have thought connecting the front and back ends of a Qt app (gnuplot + display window) would be a obvious example of a "system API". That honestly sounds like a more flexible target goal for gnuplot putput than trying to shuffle SVG files between apps and then trying to interact with it.

I can understand that building pango+cairo may be difficult, but I think at a minimum you would want to bring in gdlib. That would give you png/jpeg/sixel/kitty output terminals and also support for reading in image data. In a terminal session such as you show in the video, kitty output would go a long way toward providing the full range of graphics. OK fonts might still be a problem.

You say "I think it would be well-suited as a plugin/extension for other software", but that doesn't fit with my understanding of what a "plugin" is expected to provide. Gnuplot does not provide an API other than a text input stream and an output stream whose content depends on the terminal type. So how would it function as a plugin? Maybe I'm thinking about this the wrong way.