15 ms·

Run Homebrew Natively on Apple Silicon Arm M1

311 points by soheil 6y ago

crb002 6y ago
Most of the gnu tools are working fine. Javascript stack is still a tire fire. JVM is ok. Ruby/Python are fine.
- ericlewis 6y ago
  Not really sure what you mean. Node at least runs fine in emulation mode and it takes like 5 minutes to build node from scratch to run natively on this thing.
- teilo 6y ago
  Chrome is running great, natively, on M1, so Javascript is running just fine on the V8 engine.
- soylentgraham 6y ago
  Whats wrong with javascriptcore?
  - coldtea 6y ago
    I don't think JavascriptCore is anybody's idea of the "Javascript stack". Parent means Node/NPM/Electron. Though, I'm pretty sure he's mistaken on its status.
LeoPanthera 6y ago
Has anyone tried MacPorts? It builds everything from source anyway, so there's a reasonable chance more things will work.
- Wowfunhappy 6y ago
  General note, MacPorts does not build everything from source anymore, and it hasn't for a while. MacPorts will try to find a precompiled binary on packages.macports.org, then fall back to building from source if a binary is not available. That said—while I don't know whether ARM actually works yet, MacPorts still supports PowerPC wherever possible, so they have a long history of managing multiple architectures. I expect they'll have a somewhat easier time with ARM as a result. Edit: MacPorts does indeed support ARM as of the latest release! https://lists.macports.org/pipermail/macports-announce/2020-November/000057.html https://lists.macports.org/pipermail/macports-announce/2020-...
- teilo 6y ago
  No, it has no more reasonable chance than Homebrew. Homebrew has always supported building from source. Bottles did not originally exist. All M1 Homebrew packages are presently being built from source, because there are no Apple Silicon bottles. It is the source packages that need to be updated and patched to work on Apple Silicon, and that is true whether you use MacPorts, Homebrew, or build them yourself from scratch.
  - filmgirlcw 6y ago
    Exactly. I keep having to explain this to colleagues. For some stuff, it’s just going to take time. And I can also envision that certain packages might not get updated, necessitating a fork to patch them for M1. I’m interested in how homebrew and others will handle that (so official package x chooses not to patch/accept a patch for whatever reason, leading to a fork of package x with a patch applied), presumably to avoid namespace collisions/not giving the user what they want, there could be an error message that states that an ARM64 version doesn’t officially exist but links it to the fork and gives the option to install that instead. And then there could be a flag to always allow linked-replacements if an official patch doesn’t exist.
    - CamJN 6y ago
      since this is homebrew we are talking about the solution will be whatever is the most user hostile.
      - Hackbraten 6y ago
        Sorry if you have that impression. If you’re interested in a constructive discussion, feel free to give an example and tell me how you think we should handle it better in the future.
        wl 6y ago
        You proved yourselves to be untrustworthy by opting everyone into analytics using Google and hiding the notice in lots of terminal output. You guys doubled down on that by refusing to reconsider, saying unless you were a contributor to the project, your opinion was irrelevant. Mike McQuaid's responses as a representative of the project were user hostile, all while he tried to paint himself as the victim of abuse over the matter. If you want to regain my trust, remove the analytics function, swear off such things forever, and expel Mike McQuaid from the project. But I doubt that will happen, so MacPorts it is. And I'll encourage everyone I know to use it rather than Homebrew.
- notaplumber 6y ago
  Another option might be pkgsrc, I'm sure someone's already looking at it. https://www.pkgsrc.org/ https://www.pkgsrc.org/
  - sigzero 6y ago
    It's weird that in any homebrew/macports discussion I don't see much at all about pkgsrc. Is it not any good? Has issues? No "market share"?
    - kenada 6y ago
      The package selection is fairly limited. I tried it recently and was disappointed that neither neovim nor ripgrep are packaged. It also has little mindshare. I found out by accident that it was available for macOS.
      - sigzero 6y ago
        That's too bad. It looks pretty good command line wise.
- westoque 6y ago
  using macports wouldn't make it such that "more things will work". it's really about the applications now needing to be compiled in the ARM architecture. here are some examples: aom: https://github.com/Homebrew/homebrew-core/pull/57976 https://github.com/Homebrew/homebrew-core/pull/57976 boost: https://github.com/Homebrew/homebrew-core/pull/59257 https://github.com/Homebrew/homebrew-core/pull/59257 ... if you notice the code changes for the items above, they make changes to detect if the compile target is ARM and make the necessary changes so it would compile.
- tannhaeuser 6y ago
  I loved MacPorts, greatly preferred it over Brew, and used it all the time on Mac OS back then on my PowerBook and my dying Mac Mini, but doesn't Apple's notarization requirement make it impossible to compile from source to create runnable binaries?
  - deleted 6y ago
    [deleted]
  - armadsen 6y ago
    No. Even with Gatekeeper enabled, running binaries that you compile from source on your own machine doesn't require that they be notarized. As of Big Sur, they must be _signed_, but can be self-signed by a certificate you create locally. No need for Apple's approval in any way. I don't know what the status of supporting this new requirement in MacPorts (or Homebrew) is, but it's certainly something that can be dealt with.
    - tannhaeuser 6y ago
      Then let's hope Apple doesn't alter the deal further.
      - yoz-y 6y ago
        Why would they?
        vetinari 6y ago
        They slowly tighten the screws with each release; by now it should be noticeable for most people.
        yoz-y 6y ago
        Yes they do. But the question is, why would they make a decision that will instantly make the machine completely unusable for a substantial portion of their clientele? Also, the portion that arguably gives MacBooks and, especially, iOS devices their value.
silly-silly 6y ago
Looks likes emacs didnt run perfectly on the emulation/translation layer known as rosetta.. Maybe its not so perfect after all.
- tasogare 6y ago
  Virtualization of operating systems is not supported in Rosetta.
  - revetkn 6y ago
    Thanks...I needed a laugh
  - filmgirlcw 6y ago
    I cackled.
- Uehreka 6y ago
  I wonder if Rosetta applies to apps that are purchased from the app store or at least are compiled with Xcode, but maybe not apps compiled with gcc. Or maybe if you compile something with gcc there's a way to specify to the OS that it should run with Rosetta.
  - filmgirlcw 6y ago
    I’m sure Rosetta 2 is designed to work with gcc compiled apps but given that LLVM/Clang is largely sponsored by Apple, I’m sure the preference is on that, versus whatever version of gcc with whatever specific settings emacs is using. Just a guess though.
    - CamJN 6y ago
      I'm pretty sure the problem is that the "portable dumper" that replaces the dumpster fire that was unexec is not in fact portable across architectures.
  - saagarjha 6y ago
dchasson 6y ago
Its why does this have to be a thing now? Did anyone want this? Honestly, I have not heard anyone asking for it before or after it was released. If it's ambiguous, then why is this at top of HN?
- ggm 6y ago
  I want this. I dislike depending on rosetta. I want native, and I am saddened that Apple didn't reach out to homebrew or macports to pre-arrange something. It speaks badly of the future, they're so indifferent to the developer experience. I downvoted your comment. I think this article is spot on for HN, and I think you showed a lack of critical self-awareness questioning its relevance.
  - valuearb 6y ago
    Homebrew and Macports maintainers could have easily reached out to Apple and gotten free DTKs to port with, just like thousands of other developers. But the truth is that XCode built software is far more important to Mac users and that’s where Apples focus was. Homebrew users are less than 1% of their installed base. The other truth is the M1 hadn’t been important to Homebrew maintainers. At least not yet.
    - Wowfunhappy 6y ago
      On the MacPorts side, I know that at least Saagar Jha (who posts on HN often) did indeed have a DTK. Perhaps consequently (?), MacPorts does support ARM right now.
      - saagarjha 6y ago
        I have very little to do with MacPorts's ARM support, I'm not even a maintainer ;) Most of that infrastructure was already there from the PowerPC→Intel transition, and Apple engineers had patches for basic support ready fairly quickly. I worked a little bit on early support for some heavily-depended-on packages, but I wasn't really directly involved in the effort.
JulianWasTaken 6y ago
I too have just been running ARM Homebrew the past few days. For the most part, no real complaints. It'll depend heavily on what you install, and obviously you have to be OK with compiling things, but yeah no real complaints so far here either. Other than the Python scientific ecosystem, Rust is really the main thing in my end-user stack I'm waiting on since fzy, bat, exa, etc. still don't compile, but other than that I'm fairly OK.
- akrymski 6y ago
  Does Anaconda not work on ARM? Anyone tried this yet: https://github.com/conda-forge/miniforge/ https://github.com/conda-forge/miniforge/
- itsoktocry 6y ago
  >It'll depend heavily on what you install, and obviously you have to be OK with compiling things I guess we are closer and closer to The Year of Linux on Desktop after all!
- shepmaster 6y ago
  > Rust is really the main thing in my end-user stack I'm waiting on since fzy, bat, exa, Can you expand further? % cargo install bat Finished release [optimized] target(s) in 2m 21s Installing ~/.cargo/bin/bat Installed package `bat v0.16.0` (executable `bat`) % file $(which bat) ~/.cargo/bin/bat: Mach-O 64-bit executable arm64 % cargo install exa Finished release [optimized] target(s) in 1m 21s Installing ~/.cargo/bin/exa Installed package `exa v0.9.0` (executable `exa`) % file $(which exa) ~/.cargo/bin/exa: Mach-O 64-bit executable arm64 I don't know what you mean by [fzy], as it appears to be a C program, not Rust. See also: • The tracking issue for tier 1 support [tracking] • My intermediate README with instructions [readme] [fzy]: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy [tracking]: https://github.com/rust-lang/rust/issues/73908 https://github.com/rust-lang/rust/issues/73908 [readme]: https://github.com/shepmaster/rust/blob/silicon/silicon/README.md https://github.com/shepmaster/rust/blob/silicon/silicon/READ...
  - 6y ago
rubyn00bie 6y ago
FWIW-- the easiest way to do this is just using and probably break everything you love: export ARCHFLAGS='-arch arm64' brew install -s --HEAD pkg_name_here Nothing else needed. Honestly, the `--HEAD` part may not even be needed anymore. Realize the problem with homebrew isn't brew itself right now on the M1. I have absolutely zero doubt (go read the issues) the maintainers want to support it properly and be done with this kind of noise. The reason they can't or don't is because a lot of shit is broken still. They can't safely let you go all willis-nillis installing ARM packages because they're broken. Installing stuff from source, yourself, isn't hard if it's going to actually work... 99% of it boils down to: 1. git clone whatever_it_is 2. ./configure --prefix=/usr/local/bin 3. make 4. make install
- hk__2 6y ago
  For anyone reading this, `-s` == `--build-from-source`.
- CapriciousCptl 6y ago
  I was curious and found the package install scripts nicely organized by name here-- https://github.com/Homebrew/homebrew-core/tree/master/Formula https://github.com/Homebrew/homebrew-core/tree/master/Formul...
- swiley 6y ago
  You could also try using guix or running gentoo in a prefix. both have been running on arm since forever.
dukeofdoom 6y ago
So what's more worth the $200 in upgrade. Double the RAM, or Double the disk space?
- zimpenfish 6y ago
  I went for both because my existing 2017 MBP only has 8GB/512GB and I bump into them fairly regularly. But if it's one or the other, I'd go for memory - you can offload your disk space to a NAS/Cloud/whatever much more easily.
  - bpye 6y ago
    What stack are you using that you find the 512GB limit to be a problem? I've picked up one of the 16/512 MBPs and am wondering if I should swap it for a 16/1TB MBA, or maybe MBP but I have a little while to decide.
    - zimpenfish 6y ago
      This is personal laptop - I've got >250GB in Photos which, even on "store originals in iCloud" mode takes up a huge chunk of the 512GB. I've got several x00GB folders in Dropbox that I can't currently have on the laptop (fonts, assets, etc.) 50GB+ in ~/git. I hover around 5-10GB free space these days.
      - bpye 6y ago
        Gotcha. I store photos on a NAS so I only ever have one or two SD cards worth locally (~100GB). My git directory is pretty similar.
- gravelc 6y ago
  I just bought the base model Air. No issues with the RAM thus far, but know that the disc space is going to be an annoying limitation. Will swap it for the 512GB model in the next week or so. Absolutely stunning computer though - first time back to Apple for over 8 years for me.
gravypod 6y ago
Hopefully the pains we feel with this shift to arm will inspire compiler developers to take cross compiling seriously. I don't see a reason why a compiler can't output binaries for any (or even ALL supported) platforms with a single CLI flag like golang does.
- SheinhardtWigCo 6y ago
  Good thread on this from 2018: https://news.ycombinator.com/item?id=18732832 https://news.ycombinator.com/item?id=18732832
- 05 6y ago
  Golang can do this for the single reason of having no runtime dependencies whatsoever. Try it with literally any other language and you quickly find out that it’s no use crosscompiling to armv7 ‘in one click’ when your target doesn’t have the version of libc you’re targeting. The problem is not the compiler, it’s the build tooling.
  - beagle3 6y ago
    Zig and Nim both have excellent cross compiling support out of the box. Zig extends that excellent support to its embedded LLVM C compiler - it’s probably the easiest way to cross compile C across operating system boundaries these days.
    - sim_card_map 6y ago
      https://nim-lang.org/docs/nimc.html#cross-compilation https://nim-lang.org/docs/nimc.html#cross-compilation Nim doesn't seem to have excellent cross compiling support out of the box. It simply relies on cross platform toolchains that you have to set up. Good luck setting up cross platform GCC. Zig uses musl AFAIK? That can often be problematic.
      - audunw 6y ago
        Zig supports musl, glibc, macOS libc, and mingw I think: https://ziglang.org/download/0.7.0/release-notes.html https://ziglang.org/download/0.7.0/release-notes.html But yeah, I think musl is the main target, and it ships with the source for it
maxekman 6y ago
I think the title of this post should be “Workarounds for ARM-based Apple-Silicon Mac” as in the page, it reflects the contents better. Homebrew is only mentioned in one section. It would be better to help the maintainers, by visiting the GitHub issue, who are working hard to provide an official solution out of the box.
zebus806 6y ago
nice well done
syas 6y ago
I think I'm going to manually build things from source until Homebrew officially supports M1 and Big Sur. I don't want to deal with any sort of migration / funky re-install, personally.
- grey-area 6y ago
  Homebrew is just a way of compiling upstream packages. If homebrew is broken building from source will be broken too.
  - masklinn 6y ago
    Homebrew distributes prebuilt binary packages. It’s possible that the architecture for this is improperly set up and does not understand that different architectures exist: unlike macports, homebrew was born after the x86 transition. That’s why one user above suggests `-s`: it forces a compilation from source.
    - grey-area 6y ago
      The problems with homebrew packages at present are mostly down to projects like Go and Rust not being updated for M1 ARM yet and hence sources not compiling properly rather than a problem with homebrew itself. So users attempting to compile from original upstream sources would run into similar problems. They have an overview issue here: https://github.com/Homebrew/brew/issues/7857 https://github.com/Homebrew/brew/issues/7857
      - steveklabnik 6y ago
        Rust does have tier 2 support, but it hasn’t made its way to stable yet. This means if you did try in upstream today, it would work.
- dewey 6y ago
  > I don't want to deal with any sort of migration / funky re-install, personally. Wouldn't this just make things even messier? Some packages from Homebrew and some compiled from source that you have to remember to update manually?
gsnedders 6y ago
Perhaps silly question: what's stopping Homebrew from publishing bottles for those formulae that already compile?
- miohtama 6y ago
  I guess lack of CI infrastructure
  - samgranieri 6y ago
    Given that apple just released M1 macs, yeah that makes sense
    - gsnedders 6y ago
      To just publish those that compile, there's no need for any M1 Macs; it's as easy to compile on Intel Macs.
- mikemcquaid 6y ago
  Lack of CI infrastructure. Apple and MacStadium have given us access to some machines so hopefully this should be a temporary situation to be resolved soon.

311 points by soheil 6y ago

crb002 6y ago

Most of the gnu tools are working fine. Javascript stack is still a tire fire. JVM is ok. Ruby/Python are fine.

ericlewis 6y ago
Not really sure what you mean. Node at least runs fine in emulation mode and it takes like 5 minutes to build node from scratch to run natively on this thing.
teilo 6y ago
Chrome is running great, natively, on M1, so Javascript is running just fine on the V8 engine.
soylentgraham 6y ago
Whats wrong with javascriptcore?
- coldtea 6y ago
  I don't think JavascriptCore is anybody's idea of the "Javascript stack". Parent means Node/NPM/Electron. Though, I'm pretty sure he's mistaken on its status.

LeoPanthera 6y ago

Has anyone tried MacPorts? It builds everything from source anyway, so there's a reasonable chance more things will work.

Wowfunhappy 6y ago
General note, MacPorts does not build everything from source anymore, and it hasn't for a while. MacPorts will try to find a precompiled binary on packages.macports.org, then fall back to building from source if a binary is not available. That said—while I don't know whether ARM actually works yet, MacPorts still supports PowerPC wherever possible, so they have a long history of managing multiple architectures. I expect they'll have a somewhat easier time with ARM as a result. Edit: MacPorts does indeed support ARM as of the latest release! https://lists.macports.org/pipermail/macports-announce/2020-November/000057.html https://lists.macports.org/pipermail/macports-announce/2020-...
teilo 6y ago
No, it has no more reasonable chance than Homebrew. Homebrew has always supported building from source. Bottles did not originally exist. All M1 Homebrew packages are presently being built from source, because there are no Apple Silicon bottles. It is the source packages that need to be updated and patched to work on Apple Silicon, and that is true whether you use MacPorts, Homebrew, or build them yourself from scratch.
- filmgirlcw 6y ago
  Exactly. I keep having to explain this to colleagues. For some stuff, it’s just going to take time. And I can also envision that certain packages might not get updated, necessitating a fork to patch them for M1. I’m interested in how homebrew and others will handle that (so official package x chooses not to patch/accept a patch for whatever reason, leading to a fork of package x with a patch applied), presumably to avoid namespace collisions/not giving the user what they want, there could be an error message that states that an ARM64 version doesn’t officially exist but links it to the fork and gives the option to install that instead. And then there could be a flag to always allow linked-replacements if an official patch doesn’t exist.
  - CamJN 6y ago
    since this is homebrew we are talking about the solution will be whatever is the most user hostile.
    - Hackbraten 6y ago
      Sorry if you have that impression. If you’re interested in a constructive discussion, feel free to give an example and tell me how you think we should handle it better in the future.
      - wl 6y ago
        You proved yourselves to be untrustworthy by opting everyone into analytics using Google and hiding the notice in lots of terminal output. You guys doubled down on that by refusing to reconsider, saying unless you were a contributor to the project, your opinion was irrelevant. Mike McQuaid's responses as a representative of the project were user hostile, all while he tried to paint himself as the victim of abuse over the matter. If you want to regain my trust, remove the analytics function, swear off such things forever, and expel Mike McQuaid from the project. But I doubt that will happen, so MacPorts it is. And I'll encourage everyone I know to use it rather than Homebrew.
notaplumber 6y ago
Another option might be pkgsrc, I'm sure someone's already looking at it. https://www.pkgsrc.org/ https://www.pkgsrc.org/
- sigzero 6y ago
  It's weird that in any homebrew/macports discussion I don't see much at all about pkgsrc. Is it not any good? Has issues? No "market share"?
  - kenada 6y ago
    The package selection is fairly limited. I tried it recently and was disappointed that neither neovim nor ripgrep are packaged. It also has little mindshare. I found out by accident that it was available for macOS.
    - sigzero 6y ago
      That's too bad. It looks pretty good command line wise.
westoque 6y ago
using macports wouldn't make it such that "more things will work". it's really about the applications now needing to be compiled in the ARM architecture. here are some examples: aom: https://github.com/Homebrew/homebrew-core/pull/57976 https://github.com/Homebrew/homebrew-core/pull/57976 boost: https://github.com/Homebrew/homebrew-core/pull/59257 https://github.com/Homebrew/homebrew-core/pull/59257 ... if you notice the code changes for the items above, they make changes to detect if the compile target is ARM and make the necessary changes so it would compile.
tannhaeuser 6y ago
I loved MacPorts, greatly preferred it over Brew, and used it all the time on Mac OS back then on my PowerBook and my dying Mac Mini, but doesn't Apple's notarization requirement make it impossible to compile from source to create runnable binaries?
- deleted 6y ago
  [deleted]
- armadsen 6y ago
  No. Even with Gatekeeper enabled, running binaries that you compile from source on your own machine doesn't require that they be notarized. As of Big Sur, they must be _signed_, but can be self-signed by a certificate you create locally. No need for Apple's approval in any way. I don't know what the status of supporting this new requirement in MacPorts (or Homebrew) is, but it's certainly something that can be dealt with.
  - tannhaeuser 6y ago
    Then let's hope Apple doesn't alter the deal further.
    - yoz-y 6y ago
      Why would they?
      - vetinari 6y ago
        They slowly tighten the screws with each release; by now it should be noticeable for most people.
        yoz-y 6y ago
        Yes they do. But the question is, why would they make a decision that will instantly make the machine completely unusable for a substantial portion of their clientele? Also, the portion that arguably gives MacBooks and, especially, iOS devices their value.

silly-silly 6y ago

Looks likes emacs didnt run perfectly on the emulation/translation layer known as rosetta.. Maybe its not so perfect after all.

tasogare 6y ago
Virtualization of operating systems is not supported in Rosetta.
- revetkn 6y ago
  Thanks...I needed a laugh
- filmgirlcw 6y ago
  I cackled.
Uehreka 6y ago
I wonder if Rosetta applies to apps that are purchased from the app store or at least are compiled with Xcode, but maybe not apps compiled with gcc. Or maybe if you compile something with gcc there's a way to specify to the OS that it should run with Rosetta.
- filmgirlcw 6y ago
  I’m sure Rosetta 2 is designed to work with gcc compiled apps but given that LLVM/Clang is largely sponsored by Apple, I’m sure the preference is on that, versus whatever version of gcc with whatever specific settings emacs is using. Just a guess though.
  - CamJN 6y ago
    I'm pretty sure the problem is that the "portable dumper" that replaces the dumpster fire that was unexec is not in fact portable across architectures.
- saagarjha 6y ago

dchasson 6y ago

Its why does this have to be a thing now? Did anyone want this? Honestly, I have not heard anyone asking for it before or after it was released. If it's ambiguous, then why is this at top of HN?

ggm 6y ago
I want this. I dislike depending on rosetta. I want native, and I am saddened that Apple didn't reach out to homebrew or macports to pre-arrange something. It speaks badly of the future, they're so indifferent to the developer experience. I downvoted your comment. I think this article is spot on for HN, and I think you showed a lack of critical self-awareness questioning its relevance.
- valuearb 6y ago
  Homebrew and Macports maintainers could have easily reached out to Apple and gotten free DTKs to port with, just like thousands of other developers. But the truth is that XCode built software is far more important to Mac users and that’s where Apples focus was. Homebrew users are less than 1% of their installed base. The other truth is the M1 hadn’t been important to Homebrew maintainers. At least not yet.
  - Wowfunhappy 6y ago
    On the MacPorts side, I know that at least Saagar Jha (who posts on HN often) did indeed have a DTK. Perhaps consequently (?), MacPorts does support ARM right now.
    - saagarjha 6y ago
      I have very little to do with MacPorts's ARM support, I'm not even a maintainer ;) Most of that infrastructure was already there from the PowerPC→Intel transition, and Apple engineers had patches for basic support ready fairly quickly. I worked a little bit on early support for some heavily-depended-on packages, but I wasn't really directly involved in the effort.

JulianWasTaken 6y ago

I too have just been running ARM Homebrew the past few days. For the most part, no real complaints. It'll depend heavily on what you install, and obviously you have to be OK with compiling things, but yeah no real complaints so far here either. Other than the Python scientific ecosystem, Rust is really the main thing in my end-user stack I'm waiting on since fzy, bat, exa, etc. still don't compile, but other than that I'm fairly OK.

akrymski 6y ago
Does Anaconda not work on ARM? Anyone tried this yet: https://github.com/conda-forge/miniforge/ https://github.com/conda-forge/miniforge/
itsoktocry 6y ago
>It'll depend heavily on what you install, and obviously you have to be OK with compiling things I guess we are closer and closer to The Year of Linux on Desktop after all!
shepmaster 6y ago
> Rust is really the main thing in my end-user stack I'm waiting on since fzy, bat, exa, Can you expand further? % cargo install bat Finished release [optimized] target(s) in 2m 21s Installing ~/.cargo/bin/bat Installed package `bat v0.16.0` (executable `bat`) % file $(which bat) ~/.cargo/bin/bat: Mach-O 64-bit executable arm64 % cargo install exa Finished release [optimized] target(s) in 1m 21s Installing ~/.cargo/bin/exa Installed package `exa v0.9.0` (executable `exa`) % file $(which exa) ~/.cargo/bin/exa: Mach-O 64-bit executable arm64 I don't know what you mean by [fzy], as it appears to be a C program, not Rust. See also: • The tracking issue for tier 1 support [tracking] • My intermediate README with instructions [readme] [fzy]: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy [tracking]: https://github.com/rust-lang/rust/issues/73908 https://github.com/rust-lang/rust/issues/73908 [readme]: https://github.com/shepmaster/rust/blob/silicon/silicon/README.md https://github.com/shepmaster/rust/blob/silicon/silicon/READ...
- 6y ago

rubyn00bie 6y ago

FWIW-- the easiest way to do this is just using and probably break everything you love: export ARCHFLAGS='-arch arm64' brew install -s --HEAD pkg_name_here Nothing else needed. Honestly, the `--HEAD` part may not even be needed anymore. Realize the problem with homebrew isn't brew itself right now on the M1. I have absolutely zero doubt (go read the issues) the maintainers want to support it properly and be done with this kind of noise. The reason they can't or don't is because a lot of shit is broken still. They can't safely let you go all willis-nillis installing ARM packages because they're broken. Installing stuff from source, yourself, isn't hard if it's going to actually work... 99% of it boils down to: 1. git clone whatever_it_is 2. ./configure --prefix=/usr/local/bin 3. make 4. make install

hk__2 6y ago
For anyone reading this, `-s` == `--build-from-source`.
CapriciousCptl 6y ago
I was curious and found the package install scripts nicely organized by name here-- https://github.com/Homebrew/homebrew-core/tree/master/Formula https://github.com/Homebrew/homebrew-core/tree/master/Formul...
swiley 6y ago
You could also try using guix or running gentoo in a prefix. both have been running on arm since forever.

dukeofdoom 6y ago

So what's more worth the $200 in upgrade. Double the RAM, or Double the disk space?

zimpenfish 6y ago
I went for both because my existing 2017 MBP only has 8GB/512GB and I bump into them fairly regularly. But if it's one or the other, I'd go for memory - you can offload your disk space to a NAS/Cloud/whatever much more easily.
- bpye 6y ago
  What stack are you using that you find the 512GB limit to be a problem? I've picked up one of the 16/512 MBPs and am wondering if I should swap it for a 16/1TB MBA, or maybe MBP but I have a little while to decide.
  - zimpenfish 6y ago
    This is personal laptop - I've got >250GB in Photos which, even on "store originals in iCloud" mode takes up a huge chunk of the 512GB. I've got several x00GB folders in Dropbox that I can't currently have on the laptop (fonts, assets, etc.) 50GB+ in ~/git. I hover around 5-10GB free space these days.
    - bpye 6y ago
      Gotcha. I store photos on a NAS so I only ever have one or two SD cards worth locally (~100GB). My git directory is pretty similar.
gravelc 6y ago
I just bought the base model Air. No issues with the RAM thus far, but know that the disc space is going to be an annoying limitation. Will swap it for the 512GB model in the next week or so. Absolutely stunning computer though - first time back to Apple for over 8 years for me.

gravypod 6y ago

Hopefully the pains we feel with this shift to arm will inspire compiler developers to take cross compiling seriously. I don't see a reason why a compiler can't output binaries for any (or even ALL supported) platforms with a single CLI flag like golang does.

SheinhardtWigCo 6y ago
Good thread on this from 2018: https://news.ycombinator.com/item?id=18732832 https://news.ycombinator.com/item?id=18732832
05 6y ago
Golang can do this for the single reason of having no runtime dependencies whatsoever. Try it with literally any other language and you quickly find out that it’s no use crosscompiling to armv7 ‘in one click’ when your target doesn’t have the version of libc you’re targeting. The problem is not the compiler, it’s the build tooling.
- beagle3 6y ago
  Zig and Nim both have excellent cross compiling support out of the box. Zig extends that excellent support to its embedded LLVM C compiler - it’s probably the easiest way to cross compile C across operating system boundaries these days.
  - sim_card_map 6y ago
    https://nim-lang.org/docs/nimc.html#cross-compilation https://nim-lang.org/docs/nimc.html#cross-compilation Nim doesn't seem to have excellent cross compiling support out of the box. It simply relies on cross platform toolchains that you have to set up. Good luck setting up cross platform GCC. Zig uses musl AFAIK? That can often be problematic.
    - audunw 6y ago
      Zig supports musl, glibc, macOS libc, and mingw I think: https://ziglang.org/download/0.7.0/release-notes.html https://ziglang.org/download/0.7.0/release-notes.html But yeah, I think musl is the main target, and it ships with the source for it

maxekman 6y ago

I think the title of this post should be “Workarounds for ARM-based Apple-Silicon Mac” as in the page, it reflects the contents better. Homebrew is only mentioned in one section. It would be better to help the maintainers, by visiting the GitHub issue, who are working hard to provide an official solution out of the box.

zebus806 6y ago

nice well done

syas 6y ago

I think I'm going to manually build things from source until Homebrew officially supports M1 and Big Sur. I don't want to deal with any sort of migration / funky re-install, personally.

grey-area 6y ago
Homebrew is just a way of compiling upstream packages. If homebrew is broken building from source will be broken too.
- masklinn 6y ago
  Homebrew distributes prebuilt binary packages. It’s possible that the architecture for this is improperly set up and does not understand that different architectures exist: unlike macports, homebrew was born after the x86 transition. That’s why one user above suggests `-s`: it forces a compilation from source.
  - grey-area 6y ago
    The problems with homebrew packages at present are mostly down to projects like Go and Rust not being updated for M1 ARM yet and hence sources not compiling properly rather than a problem with homebrew itself. So users attempting to compile from original upstream sources would run into similar problems. They have an overview issue here: https://github.com/Homebrew/brew/issues/7857 https://github.com/Homebrew/brew/issues/7857
    - steveklabnik 6y ago
      Rust does have tier 2 support, but it hasn’t made its way to stable yet. This means if you did try in upstream today, it would work.
dewey 6y ago
> I don't want to deal with any sort of migration / funky re-install, personally. Wouldn't this just make things even messier? Some packages from Homebrew and some compiled from source that you have to remember to update manually?

gsnedders 6y ago

Perhaps silly question: what's stopping Homebrew from publishing bottles for those formulae that already compile?

miohtama 6y ago
I guess lack of CI infrastructure
- samgranieri 6y ago
  Given that apple just released M1 macs, yeah that makes sense
  - gsnedders 6y ago
    To just publish those that compile, there's no need for any M1 Macs; it's as easy to compile on Intel Macs.
mikemcquaid 6y ago
Lack of CI infrastructure. Apple and MacStadium have given us access to some machines so hopefully this should be a temporary situation to be resolved soon.