7

We've rented a M1 Mac Mini at a Cloud provider and installed python3 via homebrew.

However, when installing packages, we see many errors reporting wrong architecture mismatches.

pip3 install <something>

/private/var/folders/s9/94x83w5x5gv1tkw6pgcvy55r0000gn/T/pip-install-6zb2vf39/rchitect_2226cf31d84b4fbeb14084a47e566d22/.eggs/cffi-1.14.5-py3.9-macosx-11.4-arm64.egg/_cffi_backend.cpython-39-darwin.so: mach-o, but wrong architecture

Other CLI libraries work just fine with their (native) brew installations. Rosetta is not even installed.

I am not heavily into Python and searching the web did not help, hence I suspect something non-standard might be going on here.

brew info python3
[email protected]: stable 3.9.5 (bottled)
Interpreted, interactive, object-oriented programming language
https://www.python.org/
/opt/homebrew/Cellar/[email protected]/3.9.5 (3,108 files, 55.5MB) *
  Poured from bottle on 2021-05-27 at 20:07:29
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/[email protected]
License: Python-2.0

which python3
/opt/homebrew/bin/python3

Does anyone have a clue what might be going on?

Edit: Here are the architectures of the files

file /opt/homebrew/bin/python3
/opt/homebrew/bin/python3: Mach-O 64-bit executable arm64

file /private/var/folders/s9/94x83w5x5gv1tkw6pgcvy55r0000gn/T/pip-install-nq_w_w15/rchitect_e1cd9cd747dc44e2a7f69885db619a02/.eggs/cffi-1.14.5-py3.9-macosx-11-arm64.egg/_cffi_backend.cpython-39-darwin.so: Mach-O 64-bit bundle x86_64

The downloaded egg of cffi is the wrong architecture. Why is this happening and who might be the bad player here?

Improve this question
4
  • 1
    You need to see what architecture all these files etc are the command that does that is file. the output ends with : Mach-O 64-bit executable arm64
    – mmmmmm
    May 29, 2021 at 14:34
  • 1
    Do you have an example of such a package so that others can try to reproduce? And please, as already mentioned, run file /private/var/folders/s9/94x83w5x5gv1tkw6pgcvy55r0000gn/T/pip-install-6zb2vf39/rchitect_2226cf31d84b4fbeb14084a47e566d22/.eggs/cffi-1.14.5-py3.9-macosx-11.4-arm64.egg/_cffi_backend.cpython-39-darwin.so and add the result to the question.
    – nohillside ♦
    May 29, 2021 at 14:36
  • Thanks! Just added the outputs. The egg has the wrong arch - now the Q is: why is this the case? And can I somehow force/tell pip3 to use the arm64 builds?
    – pat-s
    May 29, 2021 at 14:43
  • What ios the exact pip command you are using?
    – mmmmmm
    May 29, 2021 at 18:00

4 Answers 4

Reset to default
5

Pypi does not provide an ARM package for this software for macOS. Only X86_64.

How do I know?

I actually went and looked.

https://pypi.org/project/cffi/#files

PS: As of 2021-10-13 there appears to be an ARM build of cffi in PyPy.

Improve this answer
4
  • Thanks. It is possible to tell pip to install the package from source (i.e. the tarball) or some completely different way I am overlooking? It should be possible to install/compile any python package on arm64 in general, shouldn't it?
    – pat-s
    May 30, 2021 at 7:55
  • Not necessarily. There are instructions on the cffi homepage about building it from source. That's not what pip is for.
    – Marc Wilson
    May 30, 2021 at 20:44
  • Thanks. So AFAICS the authors need to build arm64 macOS wheels by themselves and upload them to pypi. Another alternative would probably be to build the wheels locally on the machine - I'll try this next.
    – pat-s
    May 31, 2021 at 11:33
  • 1
    Another alternative would be to follow the instructions on the cffi homepage, which give specifics for macOS. But hey, pointing that out twice now.
    – Marc Wilson
    May 31, 2021 at 17:35
1

I had some similar issues with regex and typed_ast. I was running all my code from a Rosetta terminal and had installed Python from brew, via "arch -arm64 brew install".

My bodge solution was to uninstall the offending libraries and reinstall with: arch -arm64 pip install typed_ast --no-binary :all:

In practice it's probably better to be more consistent with whether you're using Rosetta or not for everything, but this worked for me.

Improve this answer
1

I had a similar problem trying to install dask. I solved it following these steps:

1/ Check which version of python are installed (I have : mac os python 2.x and 3.x, anaconda 3.8, brew 3.9):

python -m pipenv.help

Python installations found:

  • 3.9.6: /opt/homebrew/bin/python3
  • 3.9.6: /opt/homebrew/bin/python3.9
  • 3.8.8: /opt/anaconda3/bin/python3
  • 3.8.8: /opt/anaconda3/bin/python3.8
  • 3.8.2: /usr/bin/python3
  • 2.7.16: /usr/bin/python2
  • 2.7.16: /usr/bin/python2.7

2/ Use pipenv to create a 3.8 virtual environment:

pipenv install --python '/opt/anaconda3/bin/python3'
pipenv install 'dask[complete]'

Note: by default, pipenv was using the 3.9 brew version of python to create the virtual environment - which caused the problem.

3/ Activate the virtual environment and use it:

pipenv shell
Improve this answer
0

If you use Apple's python3, then it comes as a Universal Binary, so you can run it in Rosetta until the modules have caught up.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .