Stream: general

Topic: Build wasmtime for Android

view this post on Zulip Denis (May 19 2020 at 16:21):

Hi all, is there an instruction for building wasmtime for Android and iOS ?

view this post on Zulip Alex Crichton (May 19 2020 at 16:27):

Wasmtime hasn't been tested on these platforms and likely won't compile there today. The porting work necessary to get this working, though, is likely pretty small!

view this post on Zulip Denis (May 19 2020 at 16:36):

Thanks !! In free time I will try to port it ...

view this post on Zulip Denis (May 19 2020 at 16:41):

Seems like there are only some modules not compiled:
error: failed to run custom build command for backtrace-sys v0.1.36

Caused by:
process didn't exit successfully: G:\Projects\Programing\wasmtime\target\release\build\backtrace-sys-f5d9903e1591a6a7\build-script-build (exit code: 1)
--- stdout
OPT_LEVEL = Some("3")
TARGET = Some("i686-linux-android")
HOST = Some("x86_64-pc-windows-msvc")
CC_i686-linux-android = None
CC_i686_linux_android = None
TARGET_CC = None
CC = None
CFLAGS_i686-linux-android = None
CFLAGS_i686_linux_android = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
running: "i686-linux-android-clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=i686-linux-android" "-Wall" "-Wextra" "-E" "src/android-api.c"

--- stderr

error occurred: Failed to find tool. Is i686-linux-android-clang installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for wasmtime-runtime v0.16.0 (G:\Projects\Programing\wasmtime\crates\runtime)

Caused by:
process didn't exit successfully: G:\Projects\Programing\wasmtime\target\release\build\wasmtime-runtime-9ffa91a42426fedc\build-script-build (exit code: 1)
--- stdout
cargo:rerun-if-changed=src/helpers.c
TARGET = Some("i686-linux-android")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-pc-windows-msvc")
CC_i686-linux-android = None
CC_i686_linux_android = None
TARGET_CC = None
CC = None
CFLAGS_i686-linux-android = None
CFLAGS_i686_linux_android = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
running: "i686-linux-android-clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=i686-linux-android" "-Wall" "-Wextra" "-o" "G:\\Projects\\Programing\\wasmtime\\target\\i686-linux-android\\release\\build\\wasmtime-runtime-5cf986442753146a\\out\\src/helpers.o" "-c" "src/helpers.c"

--- stderr

error occurred: Failed to find tool. Is i686-linux-android-clang installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for zstd-sys v1.4.15+zstd.1.4.4

Caused by:
process didn't exit successfully: G:\Projects\Programing\wasmtime\target\release\build\zstd-sys-1eeff73c0cda7a4c\build-script-build (exit code: 1)
--- stdout
TARGET = Some("i686-linux-android")
HOST = Some("x86_64-pc-windows-msvc")
CC_i686-linux-android = None
CC_i686_linux_android = None
TARGET_CC = None
CC = None
CFLAGS_i686-linux-android = None
CFLAGS_i686_linux_android = None
TARGET_CFLAGS = None
CFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
running: "i686-linux-android-clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=i686-linux-android" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "G:\\Projects\\Programing\\wasmtime\\target\\i686-linux-android\\release\\build\\zstd-sys-f793a83e8009b4cf\\out\\zstd\\lib\\common\\debug.o" "-c" "zstd\\lib\\common\\debug.c"
running: "i686-linux-android-clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=i686-linux-android" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "G:\\Projects\\Programing\\wasmtime\\target\\i686-linux-android\\release\\build\\zstd-sys-f793a83e8009b4cf\\out\\zstd\\lib\\common\\entropy_common.o" "-c" "zstd\\lib\\common\\entropy_common.c"

--- stderr

error occurred: Failed to find tool. Is i686-linux-android-clang installed? (see https://github.com/alexcrichton/cc-rs#compile-time-requirements for help)

warning: build failed, waiting for other jobs to finish...
error: build failed

alexcrichton/cc-rs
Rust library for build scripts to compile C/C++ code into a Rust library - alexcrichton/cc-rs

view this post on Zulip Max de Danschutter (Jul 02 2020 at 14:48):

For a project that I'm working on, we are considering switching to wasmtime for our WebAssembly runtime. If I understand correctly, wasmtime currently only supports the x86_64 architecture. For the project that I'm working on, we would love to see support for Android and AArch64 in general. The wasmtime guide, section "Platform Support - JIT compiler support", states "Support for ARM, AArch64, and x86 is planned at this time". I've done some research myself but couldn't find any more info regarding those architectures. Could I have an update on the jit compiler progress for those architectures, if any.

view this post on Zulip Joey Gouly (Jul 02 2020 at 14:50):

Aarch64 support works pretty well now

view this post on Zulip Joey Gouly (Jul 02 2020 at 14:51):

(I don't know about support on Android though)

view this post on Zulip Chris Fallin (Jul 02 2020 at 14:53):

@Max de Danschutter as Joey says, aarch64 is coming along nicely, and our plan ("we" being the SpiderMonkey/Wasm team at Mozilla) is to use this as our optimizing backend for Wasm in Firefox/aarch64 -- so we're aiming for production quality

view this post on Zulip Max de Danschutter (Jul 02 2020 at 15:41):

That's great to hear, especially the production quality! Could I also ask what WebAssembly features aarch64 support currently and what is still missing in general? This would greatly help us out making the decision of moving to wasmtime!

view this post on Zulip Benjamin Bouvier (Jul 02 2020 at 15:43):

We currently have support for everything in the wasm MVP + some lightweight shipped features (bulk memory ops, etc.), and multi-value. Ongoing work is happening for reference types, SIMD and atomics. Ref types are pretty much done, they require more thorough testing + reviews, etc. SIMD and atomics have started relatively recently, in comparison.

view this post on Zulip Max de Danschutter (Jul 02 2020 at 15:48):

That is quite a lot already. It is indeed coming along nicely. Thanks for the help everyone this should be enough information!

view this post on Zulip Till Schneidereit (Jul 02 2020 at 15:48):

@Max de Danschutter the plan is to get to feature parity for Aarch64 quickly, and then keep it that way. We'll eventually expand that, but for now it'd be safe to view x86_64 and Aarch64 as the two platforms with the highest level of support.

A note on Android: we don't currently run CI tests on Android, or produce builds, but we know anecdotally that Wasmtime works on Android. We'd love to hear about issues and work together on fixing them if you run into any, though!

view this post on Zulip Max de Danschutter (Jul 02 2020 at 15:51):

When we switch to wasmtime there will be issues reported for sure as we intend to run it on as many platforms as possible. However, we will gladly help out as well!

view this post on Zulip Till Schneidereit (Jul 02 2020 at 15:51):

Sounds great — don't hesitate to reach out!

view this post on Zulip Max de Danschutter (Jul 15 2020 at 07:33):

Might be a bit off-topic but I've started my work on converting Wasmer to Wasmtime. In Wasmer, the context of the currently running WebAssemly instance, which is implicitly passed to every WebAssembly function, can have user-supplied contextual data. This is a feature we use quite a lot and I couldn't find a good alternative in Wasmtime. Since I'm no expert at Wasmtime 'yet' could someone tell me what a good alternative is in Wasmtime.

view this post on Zulip Till Schneidereit (Jul 15 2020 at 10:44):

@Alex Crichton can you weigh in on how best to do this? ^

view this post on Zulip Alex Crichton (Jul 15 2020 at 13:47):

@Max de Danschutter could you describe a bit how it's used for you? Is this something like data associated with callbacks?

view this post on Zulip Max de Danschutter (Jul 15 2020 at 14:00):

@Alex Crichton We have a ModuleContext struct, which is the host state associated with a particular module instance. We use this to map calls from modules into appropriate host side calls and to interact with memory exposed by the instance. If a more detailed explanation is needed let me know!

view this post on Zulip Alex Crichton (Jul 15 2020 at 14:02):

ah ok, so you're mainly implementing host functions that interpret arguments as pointers into wasm memory?

view this post on Zulip Yury Delendik (Jul 15 2020 at 14:05):

maybe it is something like wasm_func_new_with_env/wasm_func_callback_with_env_t ?

view this post on Zulip Till Schneidereit (Jul 15 2020 at 14:06):

@Max de Danschutter if you mainly want to get the memory, there's direct support for that, too. See the third example here: https://bytecodealliance.github.io/wasmtime/api/wasmtime/struct.Func.html#examples-1

view this post on Zulip Till Schneidereit (Jul 15 2020 at 14:06):

err, the fourth example

view this post on Zulip Max de Danschutter (Jul 15 2020 at 14:08):

Besides accessing wasm memory in host functions we also update our host state that is associated with that particular module instance.

view this post on Zulip Alex Crichton (Jul 15 2020 at 14:09):

Ah ok, so accessing memory is easily done through Caller which can access the memory of the caller so long as it's exported. Otherwise there's no native equivalent to this in Wasmtime, but you can create a Func-per-instance (it should be very cheap with Func::wrap)

view this post on Zulip Alex Crichton (Jul 15 2020 at 14:09):

with a Func-per-instance you can then close over instance-specific state to update it, would that work for your use case?

view this post on Zulip Till Schneidereit (Jul 15 2020 at 14:23):

I could easily see quite a few use cases needing to associate data with an instance, so I wonder if we should add support for that? Instances are heavy enough that adding an additional pointer-sized members should not matter at all, I'd hope

view this post on Zulip Alex Crichton (Jul 15 2020 at 14:24):

Oh for sure yeah, but callbacks, for example, don't have access to their Instance

view this post on Zulip Alex Crichton (Jul 15 2020 at 14:24):

we can certainly add the APIs but I'm not sure if it'd solve the use case here

view this post on Zulip Yury Delendik (Jul 15 2020 at 14:24):

yes, that's what wasm_func_new_with_env for, and Rust API can do it via closure

view this post on Zulip Till Schneidereit (Jul 15 2020 at 14:26):

Alex Crichton said:

Oh for sure yeah, but callbacks, for example, don't have access to their Instance

Ah, I see—good point! In that case closures are probably needed, yes. And certainly better than adding overhead to all callbacks

view this post on Zulip Max de Danschutter (Jul 15 2020 at 15:13):

Ah, capturing my ModuleContextcould work but then how should I access that within an import?

view this post on Zulip Alex Crichton (Jul 15 2020 at 15:15):

@Max de Danschutter the thinking is that you'd make a Func-per-import, and each Func is a Rust closure which can close over outer state

view this post on Zulip Max de Danschutter (Jul 15 2020 at 15:17):

Ah, of course, now I see. Quite new to Rust so closures sometimes confuse me a bit :sweat_smile:
That looks like the most straight forward way to do it in wasmtime so I'll try that out!

Last updated: Dec 23 2024 at 12:05 UTC