Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Wasmtime fails to compile on ARM architectures. #4188

Closed
riusricardo opened this issue Nov 20, 2019 · 8 comments · Fixed by #5432
Closed

Wasmtime fails to compile on ARM architectures. #4188

riusricardo opened this issue Nov 20, 2019 · 8 comments · Fixed by #5432

Comments

@riusricardo
Copy link
Contributor

OS: Ubuntu
Arch: AArch64

There is a known wasmtime issue: bytecodealliance/wasmtime#339
I'm building it after installing the required dependecies using this script

Error:

  = note: /home/ubuntu/polkadot/target/release/deps/libwasmtime_jit-7ebb7eb626f556ca.rlib(wasmtime_jit-7ebb7eb626f556ca.wasmtime_jit.cf56work-cgu.4.rcgu.o): In function `wasmtime_jit::link::link_module':
          wasmtime_jit.cf56work-cgu.4:(.text._ZN12wasmtime_jit4link11link_module17h7df126b02cc2c10fE+0xd38): undefined reference to `__rust_probestack'
          wasmtime_jit.cf56work-cgu.4:(.text._ZN12wasmtime_jit4link11link_module17h7df126b02cc2c10fE+0xd3c): undefined reference to `__rust_probestack'
          collect2: error: ld returned 1 exit status
          
error: aborting due to previous error
error: could not compile `polkadot`.

Building a Substrate based chain works well unless wasmtime is enabled.

cc: @jimpo

@pepyakin
Copy link
Contributor

pepyakin commented Nov 22, 2019

That's alright. Wasmtime doesn't support arm32 / AArch64 anyway. Created an issue for #4189

@pepyakin pepyakin transferred this issue from paritytech/polkadot Nov 22, 2019
@jimpo
Copy link
Contributor

jimpo commented Nov 22, 2019

@pepyakin The problem is that wasmtime is a default feature right now on polkadot. Ideally, wasmtime would only be a default feature on certain architectures. Is there a way to do that with Cargo?

@niklasad1
Copy link
Member

@bjornwgnr
Copy link
Member

Can this be resolved? Looks like target-specific features for dependencies has been implemented and is available in nightly as of recently: rust-lang/cargo/issues/7914

@pepyakin
Copy link
Contributor

Good to know!

Although I am not sure if we can make use of that until it stabilizes?

@niklasad1
Copy link
Member

niklasad1 commented Mar 23, 2020

Although I am not sure if we can make use of that until it stabilizes?

What do you mean by that i.e. are you referring to that substrate can't use on unstable features?

Otherwise, it could be nightly only and you can enable it by cargo +nightly build -Z features=itarget?

If -Z features=itarget is not enabled it would probably end up in a compile error with the union of all features for the specific crate but I'm not sure...

@pepyakin
Copy link
Contributor

I mean that we have one Cargo.toml that has to work both on nightly and stable and we would write there

[dependencies.`cfg(target_arch="x86_64")`.wasmtime]

how would that work when a regular user compiles substrate with stable?

@niklasad1
Copy link
Member

Ok, I see

how would that work when a regular user compiles substrate with stable?

Yeah, you are right that would bring those additional wasmtime features into the stable build.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants