marine icon indicating copy to clipboard operation
marine copied to clipboard

Marine fails to build on ARM because of old wasmer

Open monoid opened this issue 3 years ago • 4 comments

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 avatar Apr 18 '22 06:04 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 https://github.com/rust-lang/rust/issues/77071 and https://github.com/wasmerio/wasmer/issues/2808: I had to define a noop probestack function in the wasmer's lib/clif-backend/src/resolver.rs.

monoid avatar Apr 23 '22 14:04 monoid

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 https://github.com/fluencelabs/marine/issues/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.

mikevoronov avatar Apr 25 '22 09:04 mikevoronov

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`

alexbakers avatar Aug 03 '22 15:08 alexbakers

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

monoid avatar Aug 03 '22 15:08 monoid

solved by #219

mikevoronov avatar Mar 16 '23 17:03 mikevoronov