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

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.

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

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

Awesome! I didn't know that.

Thanks for sharing that will definitely come in handy!

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

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

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.

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

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 recently began using Nix as such on my current MBP - I'm a big fan!

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

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.

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

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

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

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, it does.

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

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.

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)

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

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.

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.

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.

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.

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

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.

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.

Taking a screenshot on a mac.

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

JavaScript binaries?

almost*

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

Yes.

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

That’s really not a lot of information.

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.