pip install fails on Mac M1 arm64 #1397
Comments
jonvet
changed the title
|
Try pip installing straight from the main GitHub branch using:
The reason your installation seems to be failing is that there are no Qiskit Aer binaries on pypi for M1 Macs (at least not yet- it is in the works. See #1362.), so it is attempting to build it from source, which fails because Qiskit-Aer 0.9.1 uses openmp 8.0.1. A minimum version of openmp 12.0.1 is needed to build from source for M1 Macs. There have been fixes discussed in #1286 and merged to the main branch (see pull request #1348), so installing straight from the main GitHub branch or building from source using a clone of the main GitHub branch should work. |
|
thanks @JoelHBierman I tried what you suggested in a fresh env, but it still doesn't seem to work. I can see that it's using openmp 12.0.1 now though |
|
This is bit of a strange and interesting issue. I have two M1 machines: an M1 MacBook Pro which I updated to Monterey and the newest version of Xcode command line tools along with it and an M1 Mini which I have kept running Big Sur and an older version of the command line tools just in case Monterey or Xcode had breaking changes in them. The MBP is using Clang 13.0.0 and the Mini is using Clang 12.0.5. The Aer build fails on the MBP with Monterey and clang 13.0.0, but succeeds on the Mini. This suggests that there might be some breaking change issue with either Monterey, Xcode, clang, Conan, or some combination of these and how they interact. (Of course there are other differences in the environments between the two machines so it could be due to other build dependencies as well.) I wonder if there is a way to force using Clang 12.0.x or to install an older version of Xcode command line tools? I might test this out later if I have the time, but it is something you could try. |
|
@mtreinish @vvilpas This seems to be a separate issue from the fixes discussed in #1286 and could be related to why the arm64 wheel jobs in #1362 are failing. This is possibly related to MacOS 12.0.1 and/or the latest version of Xcode command line tools/Clang. There don't appear to be any issues with Qiskit Aer running on a machine with MacOS 12.0.1 (You can pip install from the main GitHub branch with the previous Xcode command line tools version and MacOS 11, then install the wheel on MacOS 12 just fine), but there do appear to be new issues with building it on this setup. |
This PR adds CI jobs to build qiskit-aer wheels on arm64 macOS wheels. Since no CI system provides native arm64 macOS environments these CI jobs are configured to cross compile arm64 binaries from an x86_64 macOS environment. This has the limitation of not letting us execute the binaries but we can at least test building them in PR CI and publish the built binaries at release time. The two jobs added here do just that, the first is run as part of the Build workflow that runs on every proposed commit to test that we can at least compile on arm64 macOS (for supported python versions). The second job is a release publishing job that will build and publish arm64 macOS wheels to PyPI whenever there is a release. Fixes #1286 Fixes #1397
|
This was closed by #1362 because that PR added the release time CI jobs to build and publish arm64 macos wheels. The precompiled binaries will be published to pypi automatically as part of the next qiskit-aer release. If there are any issues after the next release running on macOS with arm64 feel free to reopen this or open a new issue. |
This PR adds CI jobs to build qiskit-aer wheels on arm64 macOS wheels. Since no CI system provides native arm64 macOS environments these CI jobs are configured to cross compile arm64 binaries from an x86_64 macOS environment. This has the limitation of not letting us execute the binaries but we can at least test building them in PR CI and publish the built binaries at release time. The two jobs added here do just that, the first is run as part of the Build workflow that runs on every proposed commit to test that we can at least compile on arm64 macOS (for supported python versions). The second job is a release publishing job that will build and publish arm64 macOS wheels to PyPI whenever there is a release. Fixes Qiskit#1286 Fixes Qiskit#1397
|
Hi, I'm running into Qiskit Aer version: 0.10.2 Is this because of MacOS 12.2/clang version 13.0? Thanks for any help! Cheers, |
|
Never mind, python version 3.9.8 works. |
This PR adds CI jobs to build qiskit-aer wheels on arm64 macOS wheels. Since no CI system provides native arm64 macOS environments these CI jobs are configured to cross compile arm64 binaries from an x86_64 macOS environment. This has the limitation of not letting us execute the binaries but we can at least test building them in PR CI and publish the built binaries at release time. The two jobs added here do just that, the first is run as part of the Build workflow that runs on every proposed commit to test that we can at least compile on arm64 macOS (for supported python versions). The second job is a release publishing job that will build and publish arm64 macOS wheels to PyPI whenever there is a release. Fixes #1286 Fixes #1397
This PR adds CI jobs to build qiskit-aer wheels on arm64 macOS wheels. Since no CI system provides native arm64 macOS environments these CI jobs are configured to cross compile arm64 binaries from an x86_64 macOS environment. This has the limitation of not letting us execute the binaries but we can at least test building them in PR CI and publish the built binaries at release time. The two jobs added here do just that, the first is run as part of the Build workflow that runs on every proposed commit to test that we can at least compile on arm64 macOS (for supported python versions). The second job is a release publishing job that will build and publish arm64 macOS wheels to PyPI whenever there is a release. Fixes Qiskit#1286 Fixes Qiskit#1397
|
I can reproduce the same error message on a 2019 Intel 16 inch MBP
The cause seems to be relocation of c++ headers files in recent XCode.
References:
However, this change was introduced in 2019 so I am not sure why it was working for the Mac Mini with Big Sur and an older version of command line tools.
Can we modify the path to
similar to this answer on StackOverflow? |
|
The first line in your answer should be the default That StackOverflow answer is incomplete too - if your compiler is failing to find those includes, it will likely fail to link system libraries as well. You'd need to set the Also, what exact error are you getting? You said you were reproducing the errors in the issue, which are about the LLVM dependency (which we don't get from the system), but then your comment is about failing to find standard library headers. |
|
(Note that in theory, |
|
@jakelishman Thanks for your quick reply and advice. Let me see if I can get it working. Is this issue about LLVM dependency? I must misread something but I see the line of missing |
|
The dependency is on OpenMP, and the reason "llvm" appears in its name is that we need the OpenMP library for the LLVM suite, since the system Mac compiler is In this case, it's quite possible that it's just a dirty build environment messing you up. Try removing the entire |
Informations
related to #1286 but I'm not using conda and have trouble at installation, not import
What is the current behavior?
pip install qiskit-aer==0.9.1fails with the following stacktrace:Steps to reproduce the problem
source ~/.virtualenvs/qiskit-machine-learning/bin/activatepip install qiskit-aer==0.9.1What is the expected behavior?
Suggested solutions
The text was updated successfully, but these errors were encountered: