47eee434d4
Currently our Linux binaries aren't quite as portable as they otherwise could be. There's two primary reasons for this, and one of them is that the binary is produced in a relatively recent Linux distribution (Ubuntu 16.04) which means it has a relatively recent requirement in terms of glibc versions. On OSX/Windows we can set some flags to rely on older libc implementations, but on Linux we have to actually build against an older version. This commit switches the container for the build to CentOS 6 instead of the default Ubuntu 16.04. The main trick here is also finding a C++11-capable compiler to compile wabt. Turns out though there's a helpful tutorial for this at https://edwards.sdsu.edu/research/c11-on-centos-6/ and it was as easy as installing a few packages. The second portability concern of our Linux binaries is that they link dynamically to `libstdc++.so` which isn't always installed on target systems, or even if it is it may be too old or have a different ABI. This is solved by statically linking to `libstdc++.a` in the build on Azure by doing a bit of trickery with libraries and what's available. After these results the glibc requirements drops from 2.18 (released in 2013) to 2.6 (released in 2007) and avoids the need for users to have libstdc++.so installed. We may eventually want to investigate fully-static musl binaries, but finding a musl compiler for C++ is something I'm not that good at, so I figure this is probably good enough for now.
Wasmtime: a WebAssembly Runtime.
Wasmtime is a standalone wasm-only runtime for WebAssembly, using the Cranelift JIT.
It runs WebAssembly code outside of the Web, and can be used both as a command-line utility or as a library embedded in a larger application.
Wasmtime passes the WebAssembly spec testsuite, and supports a new system API proposal called WebAssembly System Interface, or WASI.
Wasmtime includes a git submodule; in order to build it, it's necessary to obtain a full checkout, like this:
git clone --recurse-submodules https://github.com/CraneStation/wasmtime.git
To build an optimized version of Wasmtime, use Cargo:
cargo build --release
There are Rust, C, and C++ toolchains that can compile programs with WASI. See the WASI intro for more information, and the WASI tutorial for a tutorial on compiling and running programs using WASI and wasmtime, as well as an overview of the filesystem sandboxing system.
Wasmtime does not yet implement Spectre mitigations, such as those being pioneered by wasmjit, however this is a subject of ongoing research.
Additional goals for Wasmtime include:
- Support a variety of host APIs (not just WASI Core), with fast calling sequences, and develop proposals for additional API modules to be part of WASI. Reference Sysroot.
- Implement the proposed WebAssembly C API.
- Facilitate testing, experimentation, and development around the Cranelift and Lightbeam JITs.
- Develop a native ABI used for compiling WebAssembly suitable for use in both JIT and AOT to native object files.
Including Wasmtime in your project
Wasmtime exposes an API for JIT compilation through the wasmtime-jit subcrate, which depends on wasmtime-environ and wasmtime-runtime for the ABI and runtime support respectively. However, this API is not documented and subject to change. Please use at your own risk!
Build the individual crates as such:
cargo build --package wasmtime-jit
Wasmtime does not currently publish these crates on crates.io. They may be included as a git dependency, like this:
[dependencies]
wasmtime-environ = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
wasmtime-runtime = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
wasmtime-jit = { git = "https://github.com/CraneStation/wasmtime", rev = "somecommithash" }
All three crates must be specified as dependencies for wasmtime-jit to build correctly, at the moment.
It's Wasmtime.