Problems building repo on Apple M1

[querolita]

What command(s) is the bug in?

make test-all, also cargo test

Describe the bug

I was trying to build the zkevm-circuits repo on my MacBook Pro from 2021 equipped with an Apple M1 Pro chip. After setting up the right version of Go, I am getting an error when building geth-utils from the main branch:

error: failed to run custom build command for `geth-utils v0.1.0 ($HOME/WORKSPACE
/zkevm-circuits/geth-utils)`

Caused by:
  process didn't exit successfully: `$HOME/WORKSPACE/zkevm-circuits/target/debug
/build/geth-utils-b510aec9dca0a649/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=./lib/lib.go
  OPT_LEVEL = Some("0")
  TARGET = Some("aarch64-apple-darwin")
  HOST = Some("aarch64-apple-darwin")
  cargo:rerun-if-env-changed=CC_aarch64-apple-darwin
  CC_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CC_aarch64_apple_darwin
  CC_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64-apple-darwin
  CFLAGS_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64_apple_darwin
  CFLAGS_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = Some("-I/opt/homebrew/Cellar/gmp/6.2.1_1/include/")
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some("true")
  CARGO_CFG_TARGET_FEATURE = Some("aes,crc,dit,dotprod,dpb,dpb2,fcma,fhm,flagm,fp16,
frintts,jsconv,lor,lse,neon,paca,pacg,pan,pmuv3,ras,rcpc,rcpc2,rdm,sb,sha2,sha3,ssbs,
v8.1a,v8.2a,v8.3a,v8.4a,vh")
  cargo:warning=# main/gethutil
  cargo:warning=gethutil/trace.go:143:3: unknown field EIP150Hash in struct 
literal of type params.ChainConfig
  cargo:warning=gethutil/trace.go:235:95: unknown field Debug in struct literal 
of type vm.Config
  exit status: 1

  --- stderr

Error while building geth-utils: Command CC="cc" CGO_ENABLED="1"
GOARCH="arm64" GOOS="darwin" "go" "build" "-buildmode" 
"c-archive" "-o" "$HOME/WORKSPACE/zkevm-circuits/target/debug
/build/geth-utils-85563574e6aae5ad/out/libgo-geth-utils.a" "./lib/lib.go"
with args "go-geth-utils" did not execute successfully 
(status code exit status: 1).

But the error message is not very insightful.

I was wondering if you had encountered this problem before, or if it is known that this repo might not be compatible with M1. Do you have any ideas of what I try to proceed with the build?

If it makes it any easier, I was just interested in running a few tests using the Keccak circuit to learn about its measurements. Perhaps there's a simpler mechanism that does not involve setting up the whole codebase?

Thanks for your attention

Concrete steps to reproduce the bug. If it's able reproduce via testool, please share test_id from jenkins report

$ go version
go1.21.4 darwin/arm64

$ arch
arm64

$ geth version

Geth
Version: 1.13.5-stable
Architecture: arm64
Go Version: go1.21.4
Operating System: darwin
GOPATH=$HOME/go/1.21.4
GOROOT=$HOME/.goenv/versions/1.21.4

[zemse]

I can confirm that this repo works on apple silicon (personally used on M1 and M2 max). Initially, I did face some issues but after a bunch of googling and trying it got resolved. This was almost half a year ago for me, so right now I don't remember seeing this error, sorry about that.

[zemse]

If it makes it any easier, I was just interested in running a few tests using the Keccak circuit to learn about its measurements. Perhaps there's a simpler mechanism that does not involve setting up the whole codebase?

If you are only interested in the keccak, maybe you can checkout axiom's halo2 lib in which they have ported keccak circuit from this repo, but the default branch seems to have old code (before hi-lo refactor). I heard they are porting the latest changes but not sure if it's public yet.

[querolita]

Oh thank you for the idea! I will look at that for now until I figure out how to solve the building issue 😄

[pnyda]

I'm having the same error in a Intel machine. It seems to be not specific to M1.