Universal macOS Binary

[VaslD]

Can you update the Action to build universal macOS (Darwin) binary?

Not sure if GitHub Action needs special care, but in Terminal it's:

# Rust Cross-compile Support
rustup target add x86_64-apple-darwin
rustup target add aarch64-apple-darwin

# Cargo Build
SDKROOT=$(xcrun -sdk macosx --show-sdk-path) cargo build --target=x86_64-apple-darwin --release
SDKROOT=$(xcrun -sdk macosx --show-sdk-path) cargo build --target=aarch64-apple-darwin --release

# Combine Archs
mkdir -p ./target/release
lipo -create ./target/x86_64-apple-darwin/release/dovi_tool ./target/aarch64-apple-darwin/release/dovi_tool \
     -output ./target/release/dovi_tool

[quietvoid]

We already have a x86 build, so what you need is a build targeting Apple silicon?
Such as the M1/M2.

Hm, so a single binary concept exists, however: https://github.com/rust-lang/cargo/issues/8875

[VaslD]

Yes. Apple has been releasing new Macs exclusively with Apple Silicon chips for quite some time. Sooner or later x86 will be obsolete.

A universal binary combines artifacts for both architectures in a “fat” file. It runs (natively) no matter the client arch. While you can make arm64 a separate download, it’s more user-friendly to release a universal binary, so end users just pick that macOS download and wouldn’t need to worry about machine-specifics.

On Aug 28, 2022, at 21:45, quietvoid @.***> wrote:

 We already have a x86 build, so what you need is a build targeting Apple silicon? Such as the M1/M2.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[VaslD]

I went over the issue in your edit. I think the issue focuses more on building universal binaries using Rust/Cargo only.

My script only uses Rust/Cargo to build single arch releases (like usual), then relies on macOS/Xcode tools to actually produce the universal binary. I don't think this workflow is affected by that issue. All commands check out and the final binary is reported to support both archs. Since dovi_tool artifact is single-file, I also don't think there will be issues resolving dependencies.

I only have access to Intel machine at the moment. I'll find a way to test the produced binary on both platforms and report back my findings.

[ghost]

VasID's workflow is correct, it's just usually hidden by XCode. Since you're not (?) worried about Mac store submission you don't need the rest of the mess.

I'll concur that from my unfortunate time as a dev on some Clang-based witchcraft that you can just build the two architectures in sequence and slap them together with lipo. It was standard on iPhones back when I was doing it during the transitions from ARMv6 to 7 and then 7 to AArch64, and you could do debug builds for x86-based iDevice emulation that also contained the ARM binary. You can't do cross-platform (phone + desktop), or at least couldn't before, but there wasn't any reason to. Because of the way the tool I was a compiler engineer / dev on worked, our XCode integration hijacked their normal build steps and inserted lots more, and did exactly what Vas is doing when both were in binary form. It never failed unless we were dealing with XCode betas, which screw up more than a meth-starved carnie at a sobriety contest.

The only dependency issues would be externals. Since this isn't a very complicated piece of software you can statically link and avoid those problems.

I normally don't promote it but if nobody has an ARM mac, just build both and run it through lipo and see if anybody complains. dyld will take care of loading the correct architecture and if there's an accidentally malformed ARM binary in there somehow that lipo didn't catch (possibly set to a phone chip on accident?), it'll probably just silently load it anyway; since the Mx macs emulate x86 you won't know unless you debug it or trace logs from the loader.

Just my 2 cents.

[sammys]

I have a Homebrew formula in a custom tap I've been using to build what I use on macOS. I've used it for quite a while so I consider it stable enough to submit it to the main Homebrew repository. If @quietvoid is ok about it and we get enough interest I'll submit it.

[quietvoid]

The goal would be to have the CI build the binary for releases, so having a brew package isn't really relevant for this particular issue.

[quietvoid]

I've tested this on a M2 system and it works fine, so I'll add it to the CI soon.

[quietvoid]

Sample binary for testing: https://github.com/quietvoid/dovi_tool/actions/runs/3791703498 Otherwise it'll be present in the next release.