Binary from release uses openssl@1.1 which is not found on my Mac

[SichangHe]

This happens if I use cargo-binstall to install cargo-update, which pulls the binary from the release.

❯ cargo binstall cargo-update
…
❯ cargo install-update --all
dyld[99540]: Library not loaded: '/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib'
  Referenced from: '/Users/username/.cargo/bin/cargo-install-update-v11.1.1'
  Reason: tried: '/usr/local/opt/openssl@1.1/lib/libssl.1.1.dylib' (no such file), '/Users/username/.rustup/toolchains/stable-aarch64-apple-darwin/lib/libssl.1.1.dylib' (no such file), '/Users/username/lib/libssl.1.1.dylib' (no such file), '/usr/local/lib/libssl.1.1.dylib' (no such file), '/usr/lib/libssl.1.1.dylib' (no such file)
fish: Job 1, 'cargo install-update --all' terminated by signal SIGABRT (Abort)

If I compile cargo-update myself, I have no such problem.

cargo install cargo-update

I suppose the reason is that the release is built on a later macOS than mine (12.6) which caused the incompatibility.

[nabijaczleweli]

Take this up with whoever's packaging cargo-update for cargo-binstall – i.e. not me, for pretty much exactly this reason; cf. #195. I don't own the macintosh, but I think cargo-binstall should write the URL for the source it's downloading the binary from, so may be a good idea to start there.

[spitfire05]

I had a similar problem, inspecting debug logs it turns out cargo-update downloads the x86_64 binaries, even though I am on an M1. Is this fallback desired behaviour?

[nabijaczleweli]

If by that you mean that the darwin aarch64 binaries are actually amd64, then forward this to whoever's packaging cargo-update for cargo-binstall.

If you mean that cargo-binstall is just installing an amd64 package, then forward this to cargo-binstall.

[spitfire05]

It's the latter. Thanks for clarifying. Looks like it's already an issue there. https://github.com/cargo-bins/cargo-binstall/issues/857

[nabijaczleweli]

Fixed in cargo-binstall.