Add release binary for Mac m1 - apple silicon platform

[jasonleecode]

Could you plz support Mac m1 - apple silicon platform, and add release binary for it ? Thanks very much.

[simbadMarino]

Hello @jasonleecode , I'm getting this error while trying to cross-compile in my MacBook Air:

simbadmarino@Simbads-MacBook-Air go-btfs % export CGO_ENABLED=1
simbadmarino@Simbads-MacBook-Air go-btfs % make build          
go version go1.16.14 darwin/amd64
bin/check_go_version 1.15
plugin/loader/preload.sh > plugin/loader/preload.go
go fmt plugin/loader/preload.go >/dev/null
go build  "-asmflags=all='-trimpath='" "-gcflags=all='-trimpath='" -ldflags="-X "github.com/bittorrent/go-btfs".CurrentCommit=56bba5056" -o "cmd/btfs/btfs" "github.com/bittorrent/go-btfs/cmd/btfs"
# runtime/cgo
clang-13: error: argument unused during compilation: '-arch x86_64' [-Werror,-Wunused-command-line-argument]
make: *** [cmd/btfs/btfs] Error 2

I think this might be related to the compatibility issue you are reporting here... Are you experimenting the same issue? have you tried to compile the source code yourself yet?

Thanks!

[cfallin]

Hi all -- I was able to build locally on my M1 system, but wanted to improve the situation in general, so I put together a Homebrew formula over at Homebrew/homebrew-core#101491. If I understand their infrastructure correctly, if the PR is accepted, this should mean a binary build ("bottle") will be available for macOS/aarch64 (M1). This seems like a better path than trying to cross-compile a macOS/aarch64 release in the GitHub Actions CI on this repository, since GitHub Actions still (!) does not support M1 runners, and the process in the Makefile here requires running the compiler after building it.

I'll update here if the Homebrew PR is accepted!

[simbadMarino]

Thanks @cfallin , much appreciated! Let us know !!

[cfallin]

Based on feedback in Homebrew/homebrew-core#101491 it sounds like they want to avoid shipping a whole separate LLVM build, instead including a package that is just the sysroot and some wrappers that invoke either Homebrew clang or macOS system clang. It appears my macOS system clang (on macOS 12.4 at least) has no wasm32-wasi target, so Homebrew clang it is.

I'm unfortunately not well-versed in how to use a custom sysroot -- I seem to be stuck at:

cfallin@min:~ % /opt/homebrew/Cellar/llvm/13.0.1_1/bin/clang --sysroot `pwd`/wasi-sysroot -target wasm32-wasi test.c -o test.wasm
wasm-ld: error: cannot open /opt/homebrew/Cellar/llvm/13.0.1_1/lib/clang/13.0.1/lib/wasi/libclang_rt.builtins-wasm32.a: No such file or directory
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

@sunfishcode are there any docs here or elsewhere on how to use the custom sysroot? Also, in general, how do you feel about a wasi-sdk package in Homebrew that includes (i) just a wasi-sdk-clang (wasm32-wasi-clang?) shell script wrapper, or (ii) additional wrappers or some sort? Finally, do you think such a "wrap an existing clang" distribution could/should exist as part of this wasi-sdk repo?

[alterstep]

The Zig toolchain bundles LLVM, clang and wasi-libc as a standalone package, and is already available in Homebrew. Wouldn't a wasi-sdk-clang package be redundant with what zig cc already provides?

[sunfishcode]

@cfallin: Sysroots contain libraries and headers that are "shipped with the OS" in a sense. Some includes and libraries are expected to be "shipped with the compiler" and are not part of the sysroot. libclang_rt.builtins-wasm32.a is built from compiler-rt in the llvm-project tree and is in the "shipped with the compiler" category. In the wasi-sdk build, such libraries and headers are installed in $PREFIX/lib/clang/15.0.0/.

A wasi-sdk package in Homebrew that includes wasi-sdk-clang sounds good to me. It would be good to also include at least a wrapper for clang++ and ar/llvm-ar, which are commonly needed.

[sunfishcode]

Ah, also:

Finally, do you think such a "wrap an existing clang" distribution could/should exist as part of this wasi-sdk repo?

Yes. wasi-sdk applies no clang patches, so it should work with any sufficiently recent clang that has the WebAssembly backend, and I think it'd be fine to support that here in the wasi-sdk repo.