Please add `arm64-apple-darwin` binary to releases

It would be great if there was a arm64-apple-darwin artefact added to the releases page on github. The main reason is that most new Macbook users are on an arm64 cpu and it would be great to be able use a hermetic build process using releases directly from github project.

I originally requested this at Add `arm64-apple-darwin` binary to releases · Issue #56767 · llvm/llvm-project · GitHub

Thanks for reading and considering!

I found this document, but would love to read more, if it exists, about the process of being a volunteer here.

@keith The release binaries are built using the test-release.sh script which you can read about here. Once built you can upload the binaries to the LLVM release page using the upload script, and post the sha256 hash of the binaries on the Discourse thread, so they can be verified.

I do the x86 testing now but I have wanted to create arm64 binaries and test them for a long time but I don’t have access to a M1 machine. But I have a GitHub action that does all the stuff that I trigger on a new release. Feel free to poke me if you want to copy that setup or add your hardware to my action.

@tobiashieta I got an M1 Air here; I’ve built a release with the standard release script, but it might be nice to compare notes.

I’ve posted results in 15.0.0-rc1 has been tagged - #20 by DimitryAndric

Another interesting thing about macOS builds is how they tend to pull in Homebrew dependencies, therefore these binaries might not run on everybody’s system. E.g. Tobias’s x86_64 binaries pull in libzstd from /usr/local (the default Homebrew location for x86_64):

% otool -L clang+llvm-15.0.0-rc1-x86_64-apple-darwin/bin/clang-15
clang+llvm-15.0.0-rc1-x86_64-apple-darwin/bin/clang-15:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/local/opt/zstd/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.2)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)

and my arm64 binaries do the same with /opt/homebrew:

% otool -L clang+llvm-15.0.0-rc1-arm64-apple-darwin21.0/bin/clang-15
clang+llvm-15.0.0-rc1-arm64-apple-darwin21.0/bin/clang-15:
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/homebrew/opt/zstd/lib/libzstd.1.dylib (compatibility version 1.0.0, current version 1.5.2)
	/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)

I’m unsure how people normally solve this distribution problem on macOS, but there must be a way :slight_smile:

Hmmm. I think this dependency is new for 15.x. We probably should use a static zstd or disable it.

2 Likes

Did you start working on this zstd issue? Locally I’ve just been disabling it to sidestep this, but I wouldn’t mind uploading a arm release, at least for 15.x, and I doubt I should just disable it for that single arch?

I will disable it for x86 for the release. It’s quite understood that if you want extra dependencies for LLVM you have to build it yourself. So I think that just fine.

1 Like