Stream: git-wasmtime

Topic: wasmtime / Issue #1775 peepmatic-macro tests fail when ru...

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 01:09):

cfallin opened Issue #1775:

I've set up my environment to do cross-compilation and cross-architecture running of aarch64 tests from x86. This uses qemu in its userspace-emulation mode, as documented in docs/contributing-building.md.

If I try to run tests, I encounter a failure in the peepmatic-macro crate:

[cfallin@cfallin-laptop wasmtime.trunk]$ cargo test -p peepmatic-macro --target aarch64-unknown-linux-gnu --release
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.18
   Compiling proc-macro2 v1.0.10
   Compiling quote v1.0.3
   Compiling peepmatic-macro v0.1.0 (/home/cfallin/wasmtime.trunk/cranelift/peepmatic/crates/macro)
    Finished release [optimized] target(s) in 26.17s
     Running target/release/deps/peepmatic_macro-30cd4009616cf4d6
/home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6: Invalid ELF image for this architecture
error: test failed, to rerun pass '-p peepmatic-macro --lib'

Caused by:
  process didn't exit successfully: `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib64 /home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6` (exit code: 255)

The named binary is an x86-64 ELF binary, so presumably some bit of build glue is just assuming that host == target.

This issue has likely existed for a while, but I only recently encountered it because I'm newly cross-compiling; I was previously using a native aarch64 box that we've lost access to. Our CI tests exclude peepmatic, so this is not critical, but it would be nice for a cargo test --all to work by default when one has the right qemu runner set-up.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 01:09):

cfallin labeled Issue #1775:

I've set up my environment to do cross-compilation and cross-architecture running of aarch64 tests from x86. This uses qemu in its userspace-emulation mode, as documented in docs/contributing-building.md.

If I try to run tests, I encounter a failure in the peepmatic-macro crate:

[cfallin@cfallin-laptop wasmtime.trunk]$ cargo test -p peepmatic-macro --target aarch64-unknown-linux-gnu --release
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.18
   Compiling proc-macro2 v1.0.10
   Compiling quote v1.0.3
   Compiling peepmatic-macro v0.1.0 (/home/cfallin/wasmtime.trunk/cranelift/peepmatic/crates/macro)
    Finished release [optimized] target(s) in 26.17s
     Running target/release/deps/peepmatic_macro-30cd4009616cf4d6
/home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6: Invalid ELF image for this architecture
error: test failed, to rerun pass '-p peepmatic-macro --lib'

Caused by:
  process didn't exit successfully: `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib64 /home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6` (exit code: 255)

The named binary is an x86-64 ELF binary, so presumably some bit of build glue is just assuming that host == target.

This issue has likely existed for a while, but I only recently encountered it because I'm newly cross-compiling; I was previously using a native aarch64 box that we've lost access to. Our CI tests exclude peepmatic, so this is not critical, but it would be nice for a cargo test --all to work by default when one has the right qemu runner set-up.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 01:09):

github-actions[bot] commented on Issue #1775:

Subscribe to Label Action

cc @fitzgen

<details>
This issue or pull request has been labeled: "cranelift:area:peepmatic"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 01:09):

cfallin edited Issue #1775:

I've set up my environment to do cross-compilation and cross-architecture running of aarch64 tests from x86. This uses qemu in its userspace-emulation mode, as documented in docs/contributing-building.md.

If I try to run tests, I encounter a failure in the peepmatic-macro crate:

[cfallin@cfallin-laptop wasmtime.trunk]$ cargo test -p peepmatic-macro --target aarch64-unknown-linux-gnu --release
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.18
   Compiling proc-macro2 v1.0.10
   Compiling quote v1.0.3
   Compiling peepmatic-macro v0.1.0 (/home/cfallin/wasmtime.trunk/cranelift/peepmatic/crates/macro)
    Finished release [optimized] target(s) in 26.17s
     Running target/release/deps/peepmatic_macro-30cd4009616cf4d6
/home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6: Invalid ELF image for this architecture
error: test failed, to rerun pass '-p peepmatic-macro --lib'

Caused by:
  process didn't exit successfully: `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib64 /home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6` (exit code: 255)

The named binary is an x86-64 ELF binary, so presumably some bit of build glue is just assuming that host == target.

This issue has likely existed for a while, but I only recently encountered it because I'm newly cross-compiling; I was previously using a native aarch64 box that we've lost access to. Our CI tests exclude peepmatic at least for the aarch64 cross-tests, so this is not critical, but it would be nice for a cargo test --all to work by default when one has the right qemu runner set-up.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 08:51):

bjorn3 commented on Issue #1775:

peepmatic-macro is a proc-macro, which means that it must be compiled for the host architecture. How did you setup cargo to run tests using qemu?

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:08):

alexcrichton commented on Issue #1775:

TBH this actually looks like a bug in Cargo. In the meantime I've opened up https://github.com/bytecodealliance/wasmtime/pull/1778

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 14:12):

alexcrichton commented on Issue #1775:

Er actually, alternatively, this is fixed in nightly Cargo!

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 15:11):

cfallin commented on Issue #1775:

Thanks, @alexcrichton!

@bjorn3: I'm using the ~/.cargo/config.toml settings that we added recently in docs/contributing-building.md; basically this gives Cargo the ability to use qemu as a runner automatically.

view this post on Zulip Wasmtime GitHub notifications bot (May 28 2020 at 15:46):

fitzgen closed Issue #1775:

I've set up my environment to do cross-compilation and cross-architecture running of aarch64 tests from x86. This uses qemu in its userspace-emulation mode, as documented in docs/contributing-building.md.

If I try to run tests, I encounter a failure in the peepmatic-macro crate:

[cfallin@cfallin-laptop wasmtime.trunk]$ cargo test -p peepmatic-macro --target aarch64-unknown-linux-gnu --release
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.18
   Compiling proc-macro2 v1.0.10
   Compiling quote v1.0.3
   Compiling peepmatic-macro v0.1.0 (/home/cfallin/wasmtime.trunk/cranelift/peepmatic/crates/macro)
    Finished release [optimized] target(s) in 26.17s
     Running target/release/deps/peepmatic_macro-30cd4009616cf4d6
/home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6: Invalid ELF image for this architecture
error: test failed, to rerun pass '-p peepmatic-macro --lib'

Caused by:
  process didn't exit successfully: `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib64 /home/cfallin/wasmtime.trunk/target/release/deps/peepmatic_macro-30cd4009616cf4d6` (exit code: 255)

The named binary is an x86-64 ELF binary, so presumably some bit of build glue is just assuming that host == target.

This issue has likely existed for a while, but I only recently encountered it because I'm newly cross-compiling; I was previously using a native aarch64 box that we've lost access to. Our CI tests exclude peepmatic at least for the aarch64 cross-tests, so this is not critical, but it would be nice for a cargo test --all to work by default when one has the right qemu runner set-up.

Last updated: Nov 22 2024 at 16:03 UTC