I don't have an M1 Mac so I can't test, but if you send a PR to enable it and test it, that'd be much appreciated!

I think these need to be updated:

• https://github.com/cantino/mcfly/blob/master/ci/install.sh
• https://github.com/cantino/mcfly/blob/master/.travis.yml#L14

Assuming https://github.com/rust-embedded/cross can support m1 macs at this point— I'm not sure.

We may want to try something like https://github.com/XAMPPRocky/mean-bean-ci-template

Just for reference for anyone googling this: as far as I can tell mcfly works fine running on an M1 under Rosetta 2. Probably there's a performance hit but I haven't really noticed it.

I found this thread because my Terminal was complaining that mcfly was an x86_64 binary, but it turns out that it was because I updated to macOS 11.5.2, and you have to re-enable Rosetta each time you do that. You can do so by manually opening an app that's set to open in Rosetta, or with softwareupdate --install-rosetta.

I was just here an can confirm that running it under Rosetta 2 works fine and is fast. Even though having an ARM binary would indeed be desirable. I'm not Rust person therefore sadly can't help.

I've found a strange issue on an m1 mac whereby if I add mcfly init fish | source to my fish.config file, mcfly doesnt appear to work at all (ctrl+r brings up the original fish history search widget). But if I remove mcfly init fish | source from fish.config and just paste it into a new shell, mcfly starts working.

Any ideas? I cant figure out a way to set up the shell to work with mcfly automatically, basically. There are no error logs that I can see either.

I've found a strange issue on an m1 mac whereby if I add mcfly init fish | source to my fish.config file, mcfly doesnt appear to work at all (ctrl+r brings up the original fish history search widget). But if I remove mcfly init fish | source from fish.config and just paste it into a new shell, mcfly starts working.

Any ideas? I cant figure out a way to set up the shell to work with mcfly automatically, basically. There are no error logs that I can see either.

@tjkirch / @domoritz, any idea?

hmm actually - I think it might have been due to a corrupted fish install. Sorry!

I also built the latest version of fish locally which might have fixed it

Oh, good!

Just ran into this problem on an M2 mac. Thanks @ZevEisenberg for the temporary solution!

Can anyone point me in a direction for a potential fix for this? Happy to take a look and see if we can get a target working for Apple Silicon.

Fwiw, I am using cargo install mcfly so I get an Apple silicon build.

I'm assuming you are no Homebrew user, @franklinfollis. But brew has arm64 builds bottled, so brew install mcfly does the trick without installing rust or anything.

Oh, you are right. I just switched my mcfly installation to homebrew after seeing this. When I checked before, the binary wasn't arm but after reinstalling it is.

~ ❯ file -b /opt/homebrew/bin/mcfly
Mach-O 64-bit executable arm64

@tisba I actually am using Homebrew for installation!

Looking at it now, following the Homebrew install step for MacOS in the project README.md ran me into this problem in the first place:

$ brew install cantino/mcfly/mcfly
$ file -b /opt/homebrew/bin/mcfly
Mach-O 64-bit executable x86_64

whereas using @domoritz suggestion above gives the proper build for my system:

$ brew install mcfly
$ file -b /opt/homebrew/bin/mcfly
Mach-O 64-bit executable arm64

Pretty weird. I don't exactly know why these are giving different builds.

I can see that this line was changed about a year ago, but I'm not sure why; maybe @cantino can give some insight!

@franklinfollis brew install mcfly uses the homebrew maintained Formula, while brew install cantino/mcfly/mcfly uses the Formular in this repository.

Does this mean we should get rid of the cask formula?

@cantino yes let's get rid of the homebrew stuff, I was wondering how they have M1 builds, turns out they have self-hosted github action runners that they use to build the bottles.

https://brew.sh/2022/09/15/homebrew-maintainer-projects-update/

Okay, the README is updated and there is a deprecation warning in the existing tap.

@cantino I think this a good idea, change the README but keep the old tap around for other users. I do wonder how brew handles a tap going away tho, I wonder if it will fall back to the default tap (their official one).