The built release by cargo build -r has the wrong format (Malformed Mach-o file) on MacOS aarch64-apple-darwin

[Toby-Shi-cloud]

Problem

I wrote a rust program with default settings and no dependencies. It run perfectly when I used cargo build to build it.

I run cargo build -r to build a release version and tried to run it. However, the program was immediately killed by system (SIGKILL). I tried to run it with lldb, only to find error: Malformed Mach-o file.

I use file to find out why and get Mach-O executable arm64 (expected Mach-O 64-bit executable arm64), which means the executable file is 32-bit but claim to be executable on arm64.

I tried to build with cargo build -r --target aarch64-apple-darwin and the program run perfectly. However I confirm that I only have one target (aarch64-apple-darwin) installed. My environments as follows:

Steps

1. Create a rust project and leave everything by default.
2. Run cargo run to confirm the program run perfectly when building by debug. (optional)
3. Run cargo run -r to find program is killed by system.
4. Run file target/release/<project_name> to find the executable file is 32-bit.
5. Run cargo run -r --target aarch64-apple-darwin finding program run perfectly.

Possible Solution(s)

No response

Notes

I installed cargo about a month ago. cargo run -r run perfectly at that time. I tried to install wasm-pack a few days ago but failed (I'm not sure why). I am not sure whether wasm-pack affect this.

Version

cargo 1.77.1 (e52e36006 2024-03-26)
release: 1.77.1
commit-hash: e52e360061cacbbeac79f7f1215a7a90b6f08442
commit-date: 2024-03-26
host: aarch64-apple-darwin
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.4.0 (sys:0.4.70+curl-8.5.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 14.3.1 [64-bit]

[Toby-Shi-cloud]

I find out why I failed to install wasm-pack! I use cargo install wasm-pack --target aarch64-apple-darwin and succeeded! So it maybe also due to this problem.

[Toby-Shi-cloud]

Adding these lines in .cargo/config.toml solves this problem temporarily.

[build]
target = "aarch64-apple-darwin"

However, do I have a permanent approach?

[weihanglo]

Could you run which strip and check if you're using the correct one from the system not from homebrew or other places?

Could you also try the latest nightly with the build.target = "aarch64-apple-darwin" config, which should fail as expected?

This might be relevant: rust-lang/rust#122902. Also #11641

[rami3l]

IIRC this is https://stackoverflow.com/a/74686115 which is related to homebrew's binutils and has nothing to do with Cargo, at least not directly:

PATH was including path to homebrew binutils before system binaries, which led to resolving strip to /opt/homebrew/opt/binutils/bin/strip instead of /usr/bin/strip

Of course, since v1.77, Cargo has been invoking strip by default, so that issue is more visible than before.

[Toby-Shi-cloud]

IIRC this is https://stackoverflow.com/a/74686115 which is related to homebrew's binutils and has nothing to do with Cargo, at least not directly.

Of course, since v1.77, Cargo has been invoking strip by default, so that issue is more visible than before.

Work for me! Thanks!

[Toby-Shi-cloud]

Could you run which strip and check if you're using the correct one from the system not from homebrew or other places?

Could you also try the latest nightly with the build.target = "aarch64-apple-darwin" config, which should fail as expected?

This might be relevant: rust-lang/rust#122902. Also #11641

Thanks!

If I use /opt/homebrew/opt/binutils/bin/strip, cargo +nightly run -r with the build.target = "aarch64-apple-darwin" config do fail!

[Toby-Shi-cloud]

In my case, export PATH='/opt/homebrew/opt/binutils/bin:$PATH' was added by pipx, which I happened to install a few days ago. How annoying!

[weihanglo]

Thanks for help verify it. As it is expected and we've found the root cause, I am going to close this.