Arm64 whl install issue
mwatwood-cu opened this issue · comments
When installing from pip on a Mac with an Apple M1 Intel chip (arm64) in python 3.9.12 the standard pip install seems to install the incorrect shared object file (.so)
Steps to reproduce and current output in a virtual environment called venv.
pip install spiceypy
Output:
Collecting spiceypy
Using cached spiceypy-5.1.0-py3-none-macosx_11_0_arm64.whl (1.5 MB)
Requirement already satisfied: numpy>=1.17.0 in ./venv/lib/python3.9/site-packages (from spiceypy) (1.23.1)
Installing collected packages: spiceypy
Successfully installed spiceypy-5.1.0
- Test in python
Python 3.9.12 (main, Apr 5 2022, 01:52:34)
[Clang 12.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import spiceypy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<local path>/venv/lib/python3.9/site-packages/spiceypy/__init__.py", line 27, in <module>
from .spiceypy import *
File "<local path>/venv/lib/python3.9/site-packages/spiceypy/spiceypy.py", line 36, in <module>
from .utils.libspicehelper import libspice
File "/<local path>venv/lib/python3.9/site-packages/spiceypy/utils/libspicehelper.py", line 57, in <module>
libspice = CDLL(libspice_path)
File "/opt/miniconda3/lib/python3.9/ctypes/__init__.py", line 382, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/<local path>/venv/lib/python3.9/site-packages/spiceypy/utils/libcspice.so, 0x0006): tried: '<local path>/venv/lib/python3.9/site-packages/spiceypy/utils/libcspice.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e'))
- To test the contents of the listed file I run
file <local path>/venv/lib/python3.9/site-packages/spiceypy/utils/libcspice.so
Output:
: Mach-O 64-bit dynamically linked shared library x86_64
The wheel file it grabs seems to be correct name, but it doesn't end up with the correct shared object.
My current work around that is successful is to install with the --no-binary
flag
pip install spiceypy --no-binary :all:
from looking at worker logs, this appears to be an issue with both get_spice.py and the cibuildwheels project, either an actual bug in that project or an error with usage within this repo.
I think this is fixed in #453, where cibuildwheel does not attempt to update the ARCHFLAGS
early enough, and I added some bits to make it more explicit what arch to build for arm64 on macos only.
Actions failing oddly due to a pandas installation issue on the linux side, no clear cause yet...
fixed by #453