bad CPU type in executable Mac Continues

[tzmmtz]

It seems last many builds keep producing this error upon downloading and running an update.

zsh: bad CPU type in executable: ./build/avalanchego)

This never happened in the past going all the way back to testnet. Now I have to rebuild each time. Which I don't want to do during a running validator. It doesn't happen on my other Mac which is a newer model. Only this older Mac Pro 2013. Sonoma 14.7.1

Anything you can do on your side to upload an update that doesn't cause me to have to rebuild each time? Now I have to wait for this validation to end before updating as I don't want to take a chance the machine crashes.

[tzmmtz]

Update - I took a chance and ran through the process of building the binary again and now have a working avalanchego. Any way this can be fixed so I don't have to do that each time?

[marun]

Looks like the update to build on github's macos-14 runner is at fault. As per commentary on a related issue, github only supports macos-14 for arm whereas the previous macos-12 runner was amd64.

Potential options:

• switch to macos-13 which still supports amd64
• stop releasing amd64 images now since past macos-13, github won't be supplying free amd64 workers
  • this wouldn't preclude build instructions (and maybe simplifying self-build e.g. via nix)
• commit to building amd64 images via custom workers

At the least, though, the darwin images should identify their architecture in the filename.

[tzmmtz]

Would my best case be stop using this machine in the future? I don't really need to use it as my main validator is a Mac Studio. I just was adding to the decentralization pool. It's not that hard to build a binary each time but if that process won't work in the future then I might as well kill this validator machine when it ends.

[yacovm]

Would my best case be stop using this machine in the future? I don't really need to use it as my main validator is a Mac Studio. I just was adding to the decentralization pool. It's not that hard to build a binary each time but if that process won't work in the future then I might as well kill this validator machine when it ends.

If you have a different validator machine and it's your "main" (I assume from a stake perspective?) validator, then I think an easy solution would be to transfer the stake to your main validator and just not use the 2013 machine. The decentralization here is the same, as both machines are yours.

[tzmmtz]

Got it. Once the validation is done I'll repurpose the Mac Pro for something