AndrewAnnex / SpiceyPy

SpiceyPy: a Pythonic Wrapper for the SPICE Toolkit.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Arm64 whl install issue

mwatwood-cu opened this issue · comments

commented

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.

  1. 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
  1. 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'))
  1. 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...