Marine fails to build on ARM because of old wasmer

[monoid]

For example, on an Apple M1:

$ rustc --version
rustc 1.60.0 (7737e0b5c 2022-04-04)
$ cargo build
   --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-runtime-core-fl-0.17.1/src/fault.rs:289:21
    |
289 |         let fault = get_fault_info(siginfo as _, ucontext);
    |                     ^^^^^^^^^^^^^^ not found in this scope

This is the wasmer's old (0.17.x) bug wasmerio/wasmer#1025 fixed only after The Refactoring.

As a workaround, MacOS users can use x64 emulation for both toolchain and binary, but other ARM systems are out of luck.

[monoid]

For history:

I tried two approaches:

1. Switching to wasmer 2.0. As wasmer 2.0 is much more high-level, it is not easy, especially without great knowledge of marine internals.
2. Fixing the wasmer 0.17. Defining the missing get_fault_info is relatively easy, however, there are turtles the all way down: cranelift-codegen=0.59 doesn't support aarch64 well, having some unimplemented functions, and wasmer 0.17 uses some forked cranelift crates (e.g. https://crates.io/crates/wasmer-clif-fork-frontend) incompatible with stock ones, so one need backporting their changes to upgrade cranelift.

Another related issue is rust-lang/rust#77071 and wasmerio/wasmer#2808: I had to define a noop probestack function in the wasmer's lib/clif-backend/src/resolver.rs.

[mikevoronov]

Hi! Thank you for the Q.

We're using our own fork of a relatively old Wasmer 0.17.1 version that can't be compiled to any target except x86_64 due to so called DynamicFunc trampoline mechanism that could be compiled only to this target. You could find the appropriate Wasmer code here if you are interested in the details. As a result of this, I'd say that any dances around get_fault_info wouldn't help, because the issue here lies in the core component of Wasmer.

Re updating Wasmer - it's definitely not so easy, since we're using our own fork of Wasmer with more low level memory accessing support (in order for better support of values passing between modules in interface-types) and since the Wasmer API has dramatically changed after transition from 0.17.1 to 1.0.0 version. But one of part of #132 is a big refactoring of Marine core parts to introduce an abstraction layer on top of the Wasmer execution engine. I believe that after this moving to the newest Wasmer would be easier.

[alexbakers]

I am sorry, still no solution to the installation problem on the Apple M1?

error[E0425]: cannot find function `get_fault_info` in this scope
   --> /Users/jack/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-runtime-core-fl-0.17.1/src/fault.rs:289:21
    |
289 |         let fault = get_fault_info(siginfo as _, ucontext);
    |                     ^^^^^^^^^^^^^^ not found in this scope

   Compiling cargo_toml v0.8.1
   Compiling wasmer-interface-types-fl v0.23.1
For more information about this error, try `rustc --explain E0425`.
error: could not compile `wasmer-runtime-core-fl` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `marine v0.12.1`, intermediate artifacts can be found at `/var/folders/nj/nvlydv5d66dff7l9ry909hm40000gn/T/cargo-install3fOsd5`

[monoid]

@alexbakers use x86_64 emulation with Rosetta:
rustup override set nightly-x86_64-apple-darwin
in the project directory.

[mikevoronov]

solved by #219