My emacs seems to be spawning processes using x86 emuation, which then breaks certain python packages since binary modules that I install outside of emacs are for x86. A workaround I found was to create a virtualenv from with emacs since (I suspect) this then downloads x86 wheels. Also this behaviour only occurs if I start emacs with spotlight or open -a Emacs - so another workaround is to run emacs from a terminal window. (This stackoverflow post discusses similar for someone trying to wrap their project with a mac application.)

As a example if I run (shell-command-to-string "uname -a") it returns a different value from in a shell. I would prefer to not deal with any emulation or virtualenvs... but I'm sort of running out of justifiable energy debugging (see rambly post here).

What's the state of play for emacs on M1? I was suspicious that it might be doing it's own "emulation"... but I'm not so sure now. Can I get it to spawn processes natively.

To reproduce

  1. Start emacs
  2. Run (shell-command-to-string "uname -a") in emacs
  3. Run uname -a in a separate terminal
  4. The cpu architecture does not match


This problem only seems to occur if I start emacs from spotlight.

This question looks like it might be relevant: https://stackoverflow.com/questions/68199148/application-reports-different-architecture-depending-on-launch-method

1 Answer 1


Emacs runs perfectly fine natively on Apple Silicon. With Homebrew, I just brew install --cask emacs and it pulls in Emacs for macOS, installs it in /Applications, and adds a symlink to emacs. If I remember I'll re-symlink the bin/ and libexec/ directories in the app bundle to point to the arm version (neither the installer nor the Homebrew formula do this for some reason.) I don't run Rosetta at all, so the universal binary does the right thing. If you're using Emacs for macOS too, you may have to tweak symlinks yourself, namely point any emacs symlink to Emacs-arm64-11 instead of the universal binary Emacs. You can also force the architecture of any universal binary on macOS with the arch command, e.g. arch -arm64 emacs.

  • Thanks... the problem is that it seems (for example when I am using org-babel) to be spawning processes running with x86 emulation rather than using arm.
    – Att Righ
    Jun 5, 2023 at 21:48
  • Yeah, I got that from your question. The point is, ensure that you're running a native Emacs (or the arm64 arch in a universal binary). Use the arch command, or the ARCHPREFERENCE environment variable.
    – nega
    Jun 5, 2023 at 21:54
  • Hmm... I'm having a look around /Applicaiton/Emacs to work out what might be different. I'm suspicious of the launch.rs file.
    – Att Righ
    Jun 5, 2023 at 22:18
  • I'm running a native emacs I think (the "Kind" in activity monitor is Apple) and the binary name is Emacs-arm64-11. I just experimented with emacs -q and then discovered that the problem does not occur if I spawn arch from a terminal rather than spotlight (I reran with my full config)
    – Att Righ
    Jun 5, 2023 at 22:21
  • 1
    The launch.rs file is the Rust code for the app launcher ie Emacs.app/Contents/MacOS/Emacs.
    – nega
    Jun 5, 2023 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.