1

I occasionally like to use python from within org-mode in emacs? However, I've recently switched from intel architecture to m1 and this isn't working very well.

The pydantic module imports fine from my system python - but when I try to import it from within by editor python for some reason seems to be picking the wrong architecture.

From within emacs:

#+begin_src python :results output
  import sys
  print(sys.executable)
  import pydantic
#+end_src

: /Library/Developer/CommandLineTools/usr/bin/python3


Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
ImportError: dlopen(/Users/tom/Library/Python/3.9/lib/python/site-packages/pydantic/__init__.cpython-39-darwin.so, 0x0002): tried: '/Users/tom/Library/Python/3.9/lib/python/site-packages/pydantic/__init__.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/tom/Library/Python/3.9/lib/python/site-packages/pydantic/__init__.cpython-39-darwin.so' (no such file), '/Users/tom/Library/Python/3.9/lib/python/site-packages/pydantic/__init__.cpython-39-darwin.so' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
[ Babel evaluation exited with code 1 ]

From a terminal, everything works fine:

python3
Python 3.9.6 (default, Mar 10 2023, 20:16:38) 
[Clang 14.0.3 (clang-1403.0.22.14.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Could not open PYTHONSTARTUP
FileNotFoundError: [Errno 2] No such file or directory: '/Users/USER/.pythonrc.py'
>>> import sys
>>> print(sys.executable)
/Library/Developer/CommandLineTools/usr/bin/python3
>>> import pydantic
>>> 

(Note that the python executable is the same)

I did some digging and within my editor platform.processor() is returning i386 while from a python shell it is returning arm, which is confusing.

Why is the processor wrong from within my editor?

My suspicion is that it's something to do with some sort of path be it the system path, the library path, or python's path

Approaches tried

  • This question: [https://stackoverflow.com/questions/72308682/mach-o-file-but-is-an-incompatible-architecture-have-x86-64-need-arm64e] seems like it might be relevant?
  • platform is implemented in python. Looking at the source code is calling os.uname() directly and this seems to be lying about the architecture in my editor
#+begin_src python :results output
  import os
  print(os.uname())
#+end_src

#+RESULTS:
: posix.uname_result(sysname='Darwin', nodename='Danielas-MacBook-Air.local', release='22.4.0', version='Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103', machine='x86_64')

os.uname appears to be a builtin and I assume that it is implemented in C which makes it difficult to debug... but hoping that the shell uname commands works in the same way as os.uname it looks like uname -a is lying as well.

#+begin_src shell :results output
  uname -a 
#+end_src

#+RESULTS:
: Darwin computer.local 22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:41 PST 2023; root:xnu-8796.101.5~3/RELEASE_ARM64_T8103 x86_64

I'm suspicious that some sort of emulation is going on...

Att Righ
  • 1,439
  • 1
  • 16
  • 29
  • 4
    It's not lying, it's likely [Rosetta](https://en.wikipedia.org/wiki/Rosetta_(software)). Is your Terminal running in x86_64 mode? – tadman Jun 05 '23 at 15:19
  • 2
    Don't forget you can look at your process list in Activity Monitor under the "Kind" column to see if it's "Apple" (ARM) or "Intel" (x86_64). I have a feeling you're running one or more of these under Intel. – tadman Jun 05 '23 at 15:20
  • 3
    I suspect you're running an Intel Emacs, and everything within that is running in Rosetta. Try updating your Emacs to a native version. – Barmar Jun 05 '23 at 15:28
  • @tadman Thanks for the help. Ah.. I was looking for `architecture` let me look now. It's odd because emacs isn't in the list returned by `fuser /usr/libexec/rosetta/runtime` as described here (https://apple.stackexchange.com/questions/416036/tell-if-running-process-is-running-under-rosetta-or-is-m1-native-by-command-line) and activity monitor says emacs is "Apple" but if I start shell within it (eshell) the python process seems to be using i386. I've identified one workaround: create a python venv from within emacs. – Att Righ Jun 05 '23 at 15:29
  • @Barmar Potentially. I was confused because the executable had "arm" in its name `/Applications/Emacs.app/Contents/MacOS/Emacs-arm64-11` . – Att Righ Jun 05 '23 at 15:30
  • 1
    That should be native, so I was wrong there. Something it's using internally is not native, though. – Barmar Jun 05 '23 at 15:43
  • Yeah... I don't know what though. Calling `(shell-command "uname -a")` is still returning `x86_64`. I don't want to mess around with start-process. I'm looking into whether elisp has a uname function. Although I might declare defeat - use my work around and post of emacs stack exchange. – Att Righ Jun 05 '23 at 15:45
  • Interestingly if I call `python-run` instead it os.uname() of arm... but `platform.processor()` is still different. Declaring default for now.... – Att Righ Jun 05 '23 at 16:04
  • Okay I'm declaring defeat for now - going to use a workaround - once I have a little more energy. I've cross posted a [shorter and more general question ](https://emacs.stackexchange.com/questions/77504/emacs-is-not-running-processes-as-arm-process-on-m1-mac-rather-it-seems-to-x86) on the emacs stack exchange. – Att Righ Jun 05 '23 at 16:16
  • Does this answer your question? [How do I change the terminal inside Visual Studio code to use the non-Rosetta one i.e. have it use the arm64 one?](https://stackoverflow.com/questions/68781379/how-do-i-change-the-terminal-inside-visual-studio-code-to-use-the-non-rosetta-on) – Siguza Jun 06 '23 at 15:44
  • Ooh... that very much looks like the same problem, I am sort of pleased that it isn't just an emacs problem (though I've phrased it generally). I wonder if it's the same question because his is about emacs and that is about vscode... as in the long run the fixes might be different. Yeah... I can probably set the emacs shell to use the arch command as described. – Att Righ Jun 06 '23 at 16:53

0 Answers0