Run x86 Apps (including homebrew) in the Terminal on Apple Silicon | Hacker News Reader

Run x86 Apps (including homebrew) in the Terminal on Apple Silicon

notion.so

224 pointsJoshuaMulliken140 comments

There's also the "arch" command, to run commands under rosetta2

I just installed Homebrew on my new m1 MacBook Air with:

$ arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in...)"

Does this make brew compile subsequent binaries in x86 though? Or is it purely cosmetic.

Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.

Ah.. I've extracted homebrew manually and it's been compiling ARM binaries for me - which is what I wanted it to do.

If you’re ok with numerous formulae still breaking, you’ll be fine.

Off-topic: Thanks for working on Homebrew btw! It just occurred to me that I've never donated despite using it so much but now I have. Link for others:

https://github.com/homebrew/brew#donations

Thank you for the kind words, and for the donation!

Does this plan include differentiating at the Casks as well? (Thanks for the work on homebrew, I live by it - its key to my use of MacOS ..)

Casks are typically precompiled application binaries, and I assume most applications (that choose to support M1) will be Universal Binaries soon. Casks would not need to change anything.

Seemed to work fine for me... I'm now trying to install both versions of brew and spin up terminal sessions accordingly.

Are these 'good practices' for Arm Macs?:

1) When spinning up an iTerm session, figure out if it's 'Darwin x86_64' or 'Darwin arm64' - and configure paths accordingly. so they use the right brew binaries.

2) Easily double check what version of a running package/keg based on what arch is displayed in Activity Monitor.

3) That way, you can just use brew with Rosetta to start (which I did) then build up native arm Brew over time. and let the Rosetta brew fall away.

Awesome! I didn't know that.

Thanks for sharing that will definitely come in handy!

Be warned that:

> Homebrew maintainer here. We don’t officially support Big Sur yet, but installing it via Rosetta will cause it to fetch x86 bottles instead of ARM ones. At least, that’s the plan.

It will create X86 binaries instead of ARM ones. (which might be a plus at the current moment)

Stickiness of architecture is a change from how Rosetta worked in the PowerPC to Intel transition: in macOS Big Sur child processes will prefer the arch of the parent process if one is available to maximize compatibility. So for example launching x86_64 sh will cause a python invocation from that shell to also be x86_64.

The "arch" utility is your escape hatch to switch the preferred arch for the spawned process and all of its children.

Would be easy to make iTerm2 launch arch -x86_64 <shell>

I haven't tried this (don't have an M1 to hand!) but:

iterm2 -> Preferences -> Profiles -> General

Change the "Login Shell" drop down to "Command" and then enter `arch -x86_64 /usr/local/bin/zsh` or whatever your shell is.

Would `arch -x86_64 $SHELL` work?

In theory yes, since it inherits the shell env from the parent.

Haven't got the $$$ to test though.

EDIT: you could also craft an oneliner if $SHELL is not defined, something like:

`ps -T $$ | awk 'NR==2{print $NF}' | arch -x86_64 $0`

Just tried and it works :) .. Nice.

Well, this is something nice. Looks like it will help developers transition to the new architecture.

I wonder if Nix on macOS could become a better homebrew-killer by supporting Apple Silicon first. We already do aarch64-linux natively and some iOS cross compilation, so that should give us a head start.

macports is a better homebrew-killer IMHO. Follows MacOS guidelines and frameworks, integrates with the MacOS way in terms of launch agents etc.

I gave up on homebrew and switched to macports after having to change directory permissions one time too many.

Macports doesn’t install for me with no error messages.

That's very odd. Did you try to run the installer from a terminal to check if it says something?

And especially it follows common Unix traditions - packages are installed in a system wide way without permission fuck-ups.

Nix also runs and integrates with macOS too. Does macports do something that Nix doesn’t?

What we need is a cross platform package manager that installs stuff in the same place and make stuff behave the same, so shell configs can be unified between OS and not have "if" all over and expect same environments.

nix is almost that, except some packages are too old but otherwise, I have it running identically on macOS and Linux.

Homebrew puts stuff in some weird location that is /home/linuxbrew/.linuxbrew/ on Linux and that alone puts me off and it breaks if I change that location. No idea why they don't just use a path like /opt/homebrew/ for both OS and be done with it.

> No idea why they don't just use a path like /opt/homebrew/ for both OS and be done with it.

We’re now using `/opt/homebrew` for the (still experimental) ARM native Homebrew flavour.

On Linux, you’re free to choose whatever prefix you like. On Linux, Homebrew always builds from source, no matter the prefix.

Related issue[0].

I moved over from Homebrew to Nix around 5 months ago, haven't since needed to use Homebrew except for casks.

[0] "Support for Apple Silicon (aarch64-darwin)" https://github.com/NixOS/nixpkgs/issues/95903

It can replace casks too, as mac apps can also be packaged in Nix.

Where can I find out how to do this?

Installing a package is enough. For example, if you install the emacs package, Emacs.app would be available in ~/.nix-profile/Applications/Emacs.app.

If you want to launch apps you've installed with Nix using Lanchpad or Spotlight, you can use nix-darwin[1] or home-manager[2] to create a symlink in ~/Applications, though the latter seems to have temporarily disabled this feature due to conflicts between the two.

[1]: https://github.com/LnL7/nix-darwin/blob/master/modules/syste... [2]: https://github.com/nix-community/home-manager/blob/master/mo...

> Installing a package is enough. For example, if you install the emacs package, Emacs.app would be available in ~/.nix-profile/Applications/Emacs.app.

Right. I'm using home-manager on darwin and various apps like Emacs, Alacritty, Kitty are supported. However, many GUI apps are not, such as Firefox, so that's why I'm still using Homebrew's cask.

Over here I’m dying to port ArchMac to aarch64, which should be reasonably quick... if I had access to Apple Silicon hardware.

Being a lonely maintainer means I’m a bit (a lot) late on package versions and some areas are hacking, but it works on Big Sur already. But then again I’m also most probably the sole user and only target audience given the popularity of alternatives.

I was using gentoo-prefix for the longest time on MacOS.

I never got why homebrew got so popular given how terrible it is. But it was more accessible to people unfortunately. I spent some time trying to become a Gentoo developer for a while and then just gave up because there was no response.

I used to updated the clang patches to make newer clang versions compile things on osx before most of those things made it upstream.

I think it's vastly superior to macports and while I find nix interesting I don't really find it that practical. I think what makes homebrew more popular than the rest is how many precompiled packages exist. If gentoo-prefix had the same amount of precompiled packages, then I'd think it would definitely be much better for most users.

[1] https://wiki.gentoo.org/wiki/Project:Prefix

[2] https://github.com/fishman/timebomb-gentoo-osx-overlay

Which aspects of Nix would you say are "not practical"?

I wonder if the impressive compile times coming out of M1 will make pre-built binaries less important?

I recently began using Nix as such on my current MBP - I'm a big fan!

I'm glad I'm not the only one hating homebrew. It's become very anti-user in the past few years under the new maintainers. Even the original maintainer has said publicly that he doesn't like the direction the new maintainers took homebrew. All the changes the current maintainers of homebrew have made have been in the direction of "make maintaining homebrew easier so we get less questions" without any thought to the user experience those changes cause.

> without any thought to the user experience those changes cause.

Sorry you get that impression. As one of the maintainers, my impression is that each decision happens in good faith, and usually follows a controversial discussion, which puts user experience on par with maintainers’s well-being.

Examples off the top of my head:

[1]: https://github.com/Homebrew/brew/pull/9172#issuecomment-7299...

[2]: https://github.com/Homebrew/brew/issues/9177#issuecomment-72...

[3]: https://github.com/Homebrew/brew/issues/9099#issuecomment-72...

That’s not to say your feelings aren’t valid. I can see how some unpopular decisions may come across as rude, thoughtless or selfish. I’m aware that this is still a huge issue, and my feeling is that we still have a lot to learn in order to get better and more transparent at communicating.

I’m thankful for feedback like yours (even though I strongly disagree with the part that I’ve quoted). You can be sure any such feedback has a real, positive impact on where we’re heading as a project.

It's comments like this one that cause these feelings : https://github.com/Homebrew/brew/issues/7857#issuecomment-65...

pkgsrc, 'the portable package manager', support Apple Silicon:

http://pkgsrc.org/

No binary packages yet, but using it from source is pretty much a matter of downloading and extracting the 'current bz2', then:

    cd pkgrsc/bootstrap
    ./bootstrap --prefix=/opt/pkg

The default prefix is /usr/pkg, but that's protected by macOS' SPI. You might want to add /opt/pkg/bin and sbin to your $PATH. Then to install a package:

    cd pkgsrc/sysutils/nnn
    bmake install clean

Full documentation, including on how to create your own packages:

http://www.netbsd.org/docs/pkgsrc/

Thanks so much for the comment - I was trying to do that with the stable source yesterday evening with no success. Saw your tweet too, but don't have Twitter to ask you over there.

Current source works fine

That's not needed though, I manually extracted brew to /opt/homebrew per https://docs.brew.sh/Installation, and it works just fine in the native terminal.

file htop returns

htop: Mach-O 64-bit executable arm64

So this version of brew is compiling native arm64 code.

It doesn’t look like it’s fully baked yet.

https://github.com/Homebrew/brew/issues/7857

Yes I received very specific warning that I'm in uncharted waters.

But I still wanted ARM binaries, the ones I did (htop, imagemagick, tmux etc) all worked.

* not fully fermented

Fully brewed?

Hopfully it’ll be ready soon.

No, not even close. There is more that doesn't work than works. Of what I use, all I got was python3 and git. But no python3.8, no ffmpeg, no erlang, no gnutls, and on and on.

https://github.com/Homebrew/brew/issues/7857

I looked through brew.sh. Apologies if I'm missing something, but I don't think I am.

There's something really offensive about apple being too cheap to just pay some homebrew devs. And dumping the work of the arch swap onto charity effort.

I just linked you to the official page which shows what works and what doesn't work, and your response is that you're still right and everything works?

Maybe try reading what I wrote.

x0x0 sees that much is not working yet and it’s sad that Apple does not help by financing the effort.

There is no need of homebrew to install ffmpeg on Apple Silicon. I could just ./configure and make on the DTK.

ffmpeg has so many configure options, I always avoid building it with brew.

Not all of the dependencies are ready (most notably, gnutls won't yet compile), so it would be the same result.

And for what I do, the default ffmpeg in Homebrew works fine.

Keep in mind that if you're using a Homebrew version of something Apple ships with macOS, for now, you'll get x86-64 binaries while Apple's version is a universal app and will run natively on the M1.

Zsh from Homebrew: /usr/local/bin/zsh: Mach-O 64-bit executable x86_64

Apple's Zsh:

    /bin/zsh: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit
    executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
    /bin/zsh (for architecture x86_64): Mach-O 64-bit executable x86_64
    /bin/zsh (for architecture arm64e): Mach-O 64-bit executable arm64e

The Homebrew team is making progress; I've been seeing Big Sur "bottles" for a couple of days now.

That's good to know, have any of you tried bash? Bash for some reason can't be launched on multiple terminals and if tried it crashes.

Does Macports support Apple ARM? They have a Big Sur compatible version, so I'm inclined to think it can at least try compiling natively.

https://www.macports.org/install.php

Yes, it does.

Not all the ports in macports are big sur ready for x86.

There are some dependencies in autoconf about warnings vs errors in defining implicit functions that has caught out some ports and others that use the "search for the .so" instead of dlopen to check for a library.

clang now defaults to error if you turn on the implicit-function-definition warning. [1]

Big Sur doesn't actually store the .so files for system libraries, it has one big .sym/.so for all of them. [2]

[1] https://developer.apple.com/documentation/xcode-release-note... under Apple Clang Compiler:

Clang now reports an error when you use a function without an explicit declaration when building C or Objective-C code for macOS (-Werror=implicit-function-declaration flag is on). This additional error detection unifies Clang’s behavior for iOS/tvOS and macOS 64-bit targets for this diagnostic. (49917738)

[2] https://developer.apple.com/documentation/macos-release-note... under Kernel:

New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

yes if a precompiled version doesn't exist it will compile on your machine

That won't help running Docker and VirtualBox. There's also a big chance VirtualBox will never make it to M1 ;(

AS has support for virtualisation so VirtualBox will probably make it, but most likely only for running operating systems that run on ARM. There's very little preventing VB for being used as a tool to run the ARM versions of Linux or your favourite flavour of BSD, but Windows probably won't work (not until MS releases a download for Windows on ARM, at least). So, VirtualBox itself will work, but using it to run Windows applications won't.

The same is true for Docker, when someone gets a Linux VM to boot, Docker becomes a possibility just like on a normal version of macOS.

In the end I think it's only a matter of time before someone manages to combine Rosetta and virtualisation instructions (even though Apple says they don't support it) and fast-ish x64 emulation becomes a possibility. It will likely require some huge hacks that won't be allowed into the app store, but if Apple doesn't lock down the platform more with upcoming OS releases, developers and other technical-minded people will run that stuff just fine.

There are windows aarch64 builds available via various means. Although the windows arm software ecosystem is dismal.

Various means? The official way is at https://www.microsoft.com/en-us/software-download/windowsins...

VirtualBox won't be ported to any Arm64 platform, Oracle explicitly said that they wouldn't do it.

However, Parallels and VMWare Fusion will. You'll also have other solutions around.

Also, no App Store requirement on macOS at all.

> You'll also have other solutions around.

What are they?

Huh, so Apple is installing both the ARM and x86 version of apps, even on ARM computers. I guess that makes sense for portability, but I don't know if other parts of the root filesystem are one architecture only, such as the path to the kernel (unless that's a fat binary too?).

In the PPC -> x86 transition, the same hard drive could be used to boot both PPC and x86 Macs (e.g. via target disk mode or external HDDs)

That remains true today.

I good case where this would be necessary is if anything has in process plugins - I saw at least one review where the person had to restart their app (final cut maybe?) because the codec was an x86 binary - which it seemed to do more or less automatically.

Everything Apple’s responsible for is a Universal (or fat) binary.

You can boot either architecture from a Big Sur drive.

The kernel is multiple files. There’s “kernel” for Intel Macs, “kernel.release.t8020” for DTK users, and “kernel.release.t8101” for the M1.

What is the binutil to strip the x86? Is it still this command? http://hints.macworld.com/article.php?story=2005081011242266...

--edit-- Sweet it works.

cd /Applications; ditto --rsrc --arch arm64 GarageBand.app GarageBand-arm64.app

Would running X86 require licensing? If Intel doesn't say anything then could Apple in a couple of years develop their own X86 CPU by turning Rosetta into a hardware solutions? Technically it should be possible - as Transmeta has done something similar, but cannot find if they got a license from Intel or it was not needed. https://en.wikipedia.org/wiki/Transmeta

It’s likely not what Apple needs, though. They probably need a solution they can maintain long enough to let the transition through, but not any longer. They’d drop support for x86 as soon as enough applications gain support and existing x86 products get dated. Maybe 5 years?

I've read that Rosetta 2 doesn't actually emulate x86 and only emulates x86_64 which is owned by AMD, not Intel.

I was surprised to see that we got native Ruby 2.6 and Python 3.8 in the box. I thought Apple had deprecated scripting languages.

Apple deprecated direct access to system-provided interpreter installations, which is a good thing. Interpreter support was not and will not be a problem, the implication of the deprecation is you should install your own copy of those interpreters instead.

Yes, I understand that we can and should always install our own, and I have for years either with Homebrew or Conda. (Actually most of my development is python on Linux via Vagrant).

But on the M1 Mini, out of the box, you can open Terminal, and python3 launches the Python 3.8 REPL. Python 2.7 also launches out of the box. So, can you explain what you mean by "direct access" not being allowed? I'm not following your distinction.

It's damn convenient having python always available when managing a fleet of Macs with JAMF.

Python 3.8 for example got moved from the base OS install to Xcode's command line toolset. For developers, that doesn't change much.

It's in the base OS actually.

Nope. Python2 is inbox, but Python3 redirects to the Xcode/developer tools copy.

  % sw_vers
  ProductName: macOS
  ProductVersion: 11.1
  BuildVersion: 20C5048k
  % ls /Library/Python/                  
  2.7
  % ls /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/
  Headers  Python3  Resources Versions
  % ls /System/Library/Frameworks/Python.framework/
  Python  Resources Versions

Ok. Well, I don't have the Xcode command line tools installed. This is what I see:

  % ls -l /usr/bin/python*
  lrwxr-xr-x  1 root  wheel      75 Jan  1  2020 /usr/bin/python -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
  lrwxr-xr-x  1 root  wheel      82 Jan  1  2020 /usr/bin/python-config -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
  lrwxr-xr-x  1 root  wheel      75 Jan  1  2020 /usr/bin/python2 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
  lrwxr-xr-x  1 root  wheel      75 Jan  1  2020 /usr/bin/python2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
  lrwxr-xr-x  1 root  wheel      82 Jan  1  2020 /usr/bin/python2.7-config -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
  -rwxr-xr-x  1 root  wheel  137536 Jan  1  2020 /usr/bin/python3
  lrwxr-xr-x  1 root  wheel      76 Jan  1  2020 /usr/bin/pythonw -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
  lrwxr-xr-x  1 root  wheel      76 Jan  1  2020 /usr/bin/pythonw2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7

  % ls -l /usr/bin/pip*
  -rwxr-xr-x  1 root  wheel  137536 Jan  1  2020 /usr/bin/pip3

I had assumed that /usr/bin/python3 was part of the system, since it is not a symlink. But then when I do this, I see it is indeed hitting Xcode:

   % /usr/bin/python3
  objc[12852]: Class AMSupportURLConnectionDelegate is implemented in both ?? (0x20ab7e7a0) and ?? (0x1143782b8). One of the two will be used. Which one is undefined.
  objc[12852]: Class AMSupportURLSession is implemented in both ?? (0x20ab7e7f0) and ?? (0x114378308). One of the two will be used. Which one is undefined.
  Python 3.8.2 (default, Oct  2 2020, 10:45:41)
  [Clang 12.0.0 (clang-1200.0.32.27)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import os
  >>> print(os.environ['PYTHONPATH'])
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/os.py", line 675, in __getitem__
      raise KeyError(key) from None
  KeyError: 'PYTHONPATH'

So Xcode is definitely involved.

EDIT: So I uninstalled Xcode. /usr/bin/python3 is there, but it is clearly a stub file of some sort. If you run it without Xcode or Xcode command line tools installed, you get a popup to install the command line tools. So python3 is not part of the system, but the stubs for it are. Thanks for the patience.

Even more interesting, if you have Xcode, but not the command line tools, the stub launches Python3.8 from the Xcode installation. Once you install the command line tools, it then switches to launching that version. Presumably this is all because of the read-only system volume.

I can imagine many existing tools still rely on the commands being directly accessible on PATH, and Apple may be reluctant to break them outright even that’s the goal. They are declared deprecated so people would refrain from using them for new things, and move old things away from them. That’s basically what deprecation means in software, as I understand it. Those commands wouldn’t be called deprecated if Apple breaks them outright.

Right, but in that case I would not expect them to upgrade Python to 3.8.

It’s quite likely Apple still wants Python.framework to be available (which is not deprecated) and it’s easier to upgrade the whole thing.

I'm trying to run some python code (from Pycharm). Since the specific version of tensorflow i need is not compatible with M1, I already get stuck at import tensorflow. How can i tell my mac to Rosetta 2? I know when I want to run something specific from the terminal, I can use "arch -x86_64"... but what do I do here?

are there any benchmarks of x86-64 homebrew ports running under rosetta2 vs the last generation of intel macs?

how about stuff like python, webservers or java apps running in x86-64 linux docker containers?

very curious what the effects are of the new arch on common developer use cases. (without having to recompile/rebuild everything for apple arm)

Not for Homebrew but some benchmarks here: https://www.anandtech.com/show/16252/mac-mini-apple-m1-teste...

i guess the gcc bench confirms, "yep, it's not native." cool that they do as much transpilation as possible at install time, and then jit the rest at runtime though. i'm curious how this all works in context of linux container runtime and if there are additional overheads...

all that said, i think the big screwup here is that the SoC only supports two displays where the intel chipset supported three or four. only being able to drive a single external display (after years of supporting multiple) is pretty bad, i doubt jobs would have let that one slip... (no matter how much cool engineering went into making the arm arch a reality)

I haven't kept up too much about how they did this. Is this ultimately just about faking uname(2) in the homebrew scripts? I would imagine Apple would make the mach-o loader transparently run rosetta when they see an x86 binary in response to execve(2). In other words, why doesn't it "just work"?

This is because it tells Terminal (a universal binary) to launch in Rosetta, which will impose the preference on anything run inside of it. By default binaries with an arm64 slice will launch that preferentially.

Homebrew is just Ruby, so there’s no way for macOS to independently know that it should present a fake x86 system to this particular Ruby script (or shell script). But when you run an x86 binary, it should just work like you describe.

But wouldn't it load the right ruby interpreter? And anything installed via homebrew, it would also know how to exec?

The only problem I see is if you have a mix of different architectures wrt libraries.

Hi OP, sorry for the aside, but how do you take good looking terminal photos like the first pic in the post?

Taking a screenshot on a mac.

Like the window screenshot? Got it. How does it have the cool fade shadow, automatic?

https://support.apple.com/en-us/HT201361

yes, the drop shadow is automatic if you use the window capture mode.

By the way, you can capture windows without drop shadow if you hold Option while selecting the window:

1. Press CMD + Opt + 4 to enter selection mode

2. Press Space to switch to window selection mode

3. Hold Opt and click

Or just use iTerm, which is Intel-only so far.

iTerm2 3.4 (now 3.4.1) shipped a day or two ago; it's a universal binary.

I made the mistake of trying to install the nightly and somehow got iTerm instead of iTerm2. My bad. Thanks for the heads up.

Or manually install by just git cloning, so that everything else compiles for the m1, instead of using x86

Does anyone know if arm64 compiled javascript binaries will work on x86 systems?

JavaScript binaries?

Yeah, pre compiled c libraries for node js, like SQLite.

Does this mean you can run almost any app you had before M1 in x86 mode?

Yes.

almost*

No x86 virtual machines though. Apple doesnt allow emulation and virtualisation together.

when software like brew finally becomes available on Apple Silicon natively. How can I delete all this stuff I need to download under Rosetta? I don't want to have duplicate stuff

You can replace `install.sh` in the install script with `uninstall.sh`

thanks!

a little more info on rosetta2

https://en.wikipedia.org/wiki/Rosetta_(software)#Rosetta_2

That’s really not a lot of information.

no, thanks.

why do people keep using this marketing fluff word "Apple Silicon"? should just call it Apple M1

M1 is just one model. Apple Silicon is the category. There will be many other M2, M2, M2X ... etc

Well it's marketing but a descriptive one, so I am okay with playing along.

We could call it Apple ARM.

crazy apple forgot to do this. they are forgetting their base, as per usual.

Reply on news.ycombinator.com