Perseus try to run binary on cross build aarch64

[martadinata666]

I'm trying to deploy perseus using

ARG CARGO_BUILD_TARGET=aarch64-unknown-linux-gnu
RUN perseus deploy --no-system-tools-cache --no-minify-js --verbose

As cargo usual flow, cross build should be seamsless with x86_64 host

And I assume perseus try to run it at the end? How do I disable this behavior? Or correct command that only builds the app? Which obviously will fail due to mismatch architecture, perseus deploy --help seems don't have a switch to disable it.

 #24 5644.4     Blocking waiting for file lock on package cache
#24 5644.4     Blocking waiting for file lock on build directory
#24 5644.4     Finished release [optimized] target(s) in 94m 01s
#24 5644.4      Running `dist/target_engine/aarch64-unknown-linux-gnu/release/redacted-binary-name`
#24 5644.4 qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory

it detect libc6:arm64 not the cross libc6-arm64-cross https://packages.debian.org/search?searchon=contents&keywords=%2Flib%2Fld-linux-aarch64.so.1&mode=path&suite=stable&arch=any

Update: in the end, I manually replace the binary after perseus deploy from at x86_64 target.
Thanks you ☕

[arctic-hen7]

I think --cargo-engine-args should work for this? That should let you specify a custom target.

[martadinata666]

yes, set env or passing will do, but the problem is perseus try to run the binary in the end, resulting failure. I browse around the help there is --no-run at perseus serve but perseus deploy don't accept this.

[arctic-hen7]

Oh I see! The deploy command shouldn't run the binary though...

[martadinata666]

yeah, that's also my assumption also: just build and place to pkg path, Is some kind of smoke test from perseus deploy to check is the binary run? thing? 🤔

[arctic-hen7]

Just realised: Perseus runs a separate build stage to produce all the static artifacts, and it will try to run the binary to perform that stage! I could add a mechanism within the CLI to detect cross-compilation and double-compile: once for the build (using your local target) and once for the final binary, which should solve this problem.