ImportError for Qiskit Aer built from source for MacOS arm64 #1286
Comments
|
Hi. Unfortunately I don't have a MacOS arm64 to test, but it seems is trying to use some symbols from |
|
I have talked about this with Matthew Treinish on the Qiskit Aer Slack channel. He mentioned that there is some error in scikit-build that causes it to ignore the CPU architecture and instead build for the x86_64 architecture under the covers. He suggested building scikit-build from source from the GitHub master branch since there is a fix there, which I have done for these build log files. There also appear to be issues with Conan and targeting the arm64 architecture (even if you change |
|
Preparing a M1 Mac and failing to setup qiskit-aer with a very similar error as described in @JoelHBierman's build2.log, I replaced the z_Linux_asm.S file created in ~/.conan/data/llvm-openmp/8.0.1///source/source_subfolder/runtime/src on first build with the current file on branch main from https://github.com/llvm/llvm-project/tree/main/openmp This avoids the unknown directive error (size __kmp_unnamed_critical_addr,8). With a 'pip install qiskit-aer' works as well as building qiskit-aer from source (using miniforge and description https://qiskit.org/documentation/getting_started.html#install-qiskit-aer). For full qiskit I got h5py via conda. I didn't test, just ran the lines above (with 'method' param) and a hello. Obviously, this not a final fix. |
|
@willemrc Wow! That did the trick! The ImportError is gone. Now I just need to do some testing to make sure everything is working as intended. |
|
nice! If I understood correctly, we just need to upgrade the version of If that doesn't work we'll need to add latest openmp release to conan center. |
|
@vvilpas @JoelHBierman well, I would bet on a openmp version > 10 (max. version on conan center), so @vvilpas's last comment line probably applies. As z_Linux_asm.S line 1752 in openmp v 10 still looks like it contains the directive at first sight. |
|
@vvilpas @JoelHBierman, same error with openmp 10.0.0:
After replacing z_Linux_asm.S with current one again, it builds. Still, I didn't test building after replacement of whole openmp source with current main branch. |
|
ok, I'll try to add latest |
|
Same issue, here. Tried as well with 10.0.0. I can not find any higher version in conan.io yet: https://conan.io/center/search/llvm-openmp |
|
@vvilpas I have the .whl file for macosx-arm64 binaries for qiskit-aer 0.8.2 saved to my computer. After a few months of using it regularly to run qiskit-aer natively for this platform, I have not encountered any problems with it. The speed-up of running Aer natively as opposed to running it through Rosetta 2 is quite significant and I imagine this would be valuable for others to be able to use. I noticed that this binary is not published on pypi as of right now. I am relatively new to this sort of thing, so my question to you and the IBM team is this: Is there a proper way for me (or others, since I am definitely not the only or the first person to build qiskit-aer for this platform) to contribute to Qiskit by providing this binary file so that others do not have to go through this same annoying process? If so, what is the way to go about doing so? I imagine that simply posting the .whl file here for people to install using pip is not the way to do it for multiple reasons. (i.e. installing a file some stranger posted on GitHub seems like a poor security practice and a limited number of people would see it here anyways.) |
|
@mario-s The temporary fix given by @willemrc above should do the trick even with openmp 10.0.0. You don't necessarily need openmp > 10.0.0. to get it to work. For now, you only need the one Of course, in the long term Qiskit needs openmp > 10.0.0 so that anyone who tries to install Qiskit on M1 doesn't need to know that the problem lies in this one file in some directory on their machine and that the solution lies in some GitHub branch somewhere. Qiskit is meant to be be widely accessible to people with different levels of experience. |
|
@JoelHBierman the only mechanism we really allow for publishing official builds is automated in CI to both avoid errors and add some traceability to the origin of the builds. Do you have a step by step on what extra manual things you needed to do to get it built on your arm64 mac? The builds published to pypi are automated using cibuildwheel the config is here: https://github.com/Qiskit/qiskit-aer/blob/main/.github/workflows/deploy.yml ). So to publish mac arm64 binaries we'll have to add a job for that (which will cross compile because ci is only x86_64 mac). For example, we do this on terra: https://github.com/Qiskit/qiskit-aer/blob/main/.github/workflows/deploy.yml and retworkx: https://github.com/Qiskit/retworkx/blob/main/.github/workflows/wheels.yml#L205-L231 We're preparing a release now so pushing a PR soon would let us publish a precompiled binary for the next release. |
|
@JoelHBierman I have been updating the PR to Conan for OpenMP 12.0.1 and everything is green now (conan-io/conan-center-index#6312), although there was a weird issue with running in macos in Debug mode failing if less than 5 threads were used. Once they approve it and merge it we can try to use that version in AER and check that everything works. In the meantime maybe you can follow @mtreinish approach, just in case conan PR merge takes too much time or it doesn't work at the end. |
|
Since this was a while ago that I built Aer, I built it again from source just now. Here are the steps to reproduce it as complete as it occurs to me to make them. If there's any other info you need, let me know. This is starting from a fresh Miniconda3 environment.
Now at this point I tried just running the command
In particular we still get the error message that @willemrc mentions above:
so to get around this error, we can replace the After making this file replacement, I ran the terminal command
I ran the following snippet of code just so I could verify on Activity Monitor that it is indeed running natively: And indeed it does appear to be running natively without issue. (This is just some simple code copied from one of the Qiskit tutorials, looped over enough times so that the program runs long enough for me to verify on Activity Monitor that it's running natively and not through Rosetta 2.) The one and only issue really seems to be that |
|
I can confirm that the instructions from @JoelHBierman also worked for me. Thanks a lot! |
|
Thank you for posting detailed instructions, that is super helpful for everyone currently stuck on an m1 mac right now. Unfortunately, I don't think that will be trivial to automate in CI since it involves coordinating modifying conan's source cache with an assembly file pulled from git, which will be tricky to get right (or building openmp from source prior to the wheel builds and disabling conan). Especially since the aer 0.9.0 is pending as soon as #1344 merges I don't think publishing arm64 wheels is viable for this release. But when @vvilpas's conan pr merges and conan is hosting a version of openmp that works on arm64 mac we can prepare a patch release (0.9.1) that will publish arm64 (or universal2) wheels. |
|
Conan |
|
build.log Note: It does create the directory What I see as noteworthy in the error message in the build.log file is that some package is trying to build for the platform macosx-10.9-arm64, despite me specifying it to build for macosx-11.0-arm64. A macosx-10.9-arm64 file is nonsense because Mac arm64 chips are not backwards compatible with macOS < 11.0. (My understanding is that the official version number of macOS Big Sur is 11.0 and above). Because the error seemed to be happening in the I manually changed I then run the command and sure enough it does seem to be running natively for M1. Interestingly, if I go back to the directory The bottom one labeled with macosx-11.0 is the one that was originally generated during my first build attempt that I manually changed. The top one seems to have been generated during my second build attempt (Notice that it was generated 3 minutes after the bottom one) but it built for macosx-11.0-arm64 anyways. Another interesting thing that I noticed is that after my second build attempt, I navigated back to the I am not sure what exactly is going on here because the manual changes I had to do this time around were not necessary last time. Would you like me to run tests on this build anyways? And are the tests you referring to the ones mentioned at: https://github.com/Qiskit/qiskit-aer/blob/daae9cf6039c9f14f7cc3ddc56a252ee686722fc/CONTRIBUTING.md ? I only ran my one minimal test given above but I imagine there are more thorough tests that have to be passed for official builds. |
|
Wow! I guess the problem with 10.9 being forced comes from here: Lines 90 to 96 in 2abc0d9 Maybe commenting that line 94 you don't need to do those manual adjustments? Sorry, but without a M1 I can't help much more. |
|
Yes, give me one second and I'll test it making that change. I will also note that I did try and see what happens if I simply run the command
so one way or another one needs to specify macOS-11.0 I think. UPDATE: I just manually changed the name of this .whl file to Be right back while I try building with that one line commented out. |
|
Commenting out that one line does appear to allow it to build, but only if you specify the build version 11.0 as NOTE: In a matter of weeks Apple is going to be releasing MacOS Monterey which (unless I am mistaken) will go by the version number 12.0. It seems that Apple is changing their longstanding version numbering convention from 10.x.y to x.y.z where x = 11 for Big Sur, x = 12 for Monterey, probably x = 13 for MacOS some-naturey-place, ect... Whatever changes need to be made to Qiskit, they should probably be made to anticipate this new version numbering so we don't run into this issue for every version of MacOS going forward. |
|
Thanks for the testing @JoelHBierman! One thing, because I sometimes forgot and caused trouble, did you delete the |
|
Every time I ran a new test, I did so using a fresh environment, so there should be no _skbuild to delete before rebuilding. So if I make the change regarding llvm-openmp and comment out the forced version line, it should be completely separate from the other build environments. So what's puzzling to me is that even in a fresh environment where I use a fresh qiskit-aer GitHub clone, if I make the two changes mentioned earlier and I specify version 11.0 in the wheel build, it will work and install just fine, but everything in _skbuild is still named incorrectly. I guess that doesn't matter a whole lot as long as it builds, but if someone trying to build Aer from source doesn't know that they need to specify |
|
It seems like in the The only thing that worries me about implementing something like this is that some people might want to have a mix of some Conda environments which are arm64 native and some which run non-natively through Rosetta-2 because other non-qiskit packages might be a pain to build from source if they don't publish arm-native binaries. Up until recently I did this because I couldn't get pyscf to build from source for macosx-arm64, which is important if you use the PYSCFDrivers in Qiskit-nature. So I had some x86 environments and some arm64 environments, where I would generate the pyscf drivers in an x86 environment, save it to a HDF5Driver file, then load it in an arm64 environment. Or some newcomers who just bought a new Mac and just started learning how to code might not know how to install Miniconda to get all the arm64 package dependencies since Anaconda doesn't run natively for arm64 yet and a lot of packages are not published for arm64 on pypi yet. My point being here is that I don't know if changing this file in this way to detect CPU architecture would cause problems for people who run Qiskit through rosetta-2. (i.e. if one is running an environment through rosetta-2, does the CPU architecture get detected as x86 or arm64?) |
|
It's been a long time since I work on AER so I didn't remember but I think I might have find the problem. In Line 111 in daae9cf Can you substitute with this: and try again when you have time. No hurries! |
|
Making that change, in addition to the other changes already mentioned, seems to do the trick. It builds and installs the wheel without me needing to specify the version number as 11.0. |
|
Just out of curiosity, from a fresh environment and a fresh GitHub clone, I also tried building where I made the changes to the llvm-openmp version and to the cmake_args in setup.py, but made no manual changes to the CMakeLists.txt file. That also builds successfully without me needing to specify version 11.0. |
|
Yes, I think we need to update Catch2 to be compatible with macos arm64. I have updated in my PR to the |
|
The scipy build thing is a packaging bug, the setup.py lists scipy as a build requirement. Setuptools tries to install packages in the build requirements using it's own mechanism instead of pip and often fails to find packages that are preinstalled (especially if they're installed via conda). I think the fix for that is to move: https://github.com/Qiskit/qiskit-aer/blob/main/setup.py#L71 to https://github.com/Qiskit/qiskit-aer/blob/main/setup.py#L90 since scipy shouldn't be a build requirement. You also should be able to workaround this by using |
|
Okay, we are making some progress here. I manually made all the changes to a fresh clone of the current Qiskit-Aer GitHub main branch given in the PR that @vvilpas made. I also manually made the changes that @mtreinish made regarding the way Scipy is handled in C++ Tests: I ran Terra integration tests: I run |
|
I just pushed up #1353 to fix the scipy issue |
mtreinish
added
the
stable-backport-potential
|
I've tagged this as stable backport potential because fixing this and adding ci automation for publishing arm64/universal2 wheels on macOS is the last blocker for a pending 0.9.1 release |
|
What's the status of automatically building the universal wheels? Is it something that can ready to go for the 0.9.1 patch release? @vvilpas @mtreinish |
|
It's still not quite working in CI even with #1348 . I pushed up a test PR in #1362 to verify the CI config and conan is having trouble resolving we're in a cross-compilation configuration for the ci wheel jobs. I'll need some help to figure out how to explicitly configure conan to use arm64 instead of x86_64 there because it doesn't look like it's doing the right thing. |
|
In #1362 it appears to be trying to build an arm64 wheel for python 3.8. To my knowledge, the minimum version of python that officially supports MacOS arm64 is 3.9.1 (Unless there are cross-compiled builds of <= 3.8. on conda forge or something.). That could be why that build is failing. I don't know enough to know why the other two tests are failing. EDIT: It appears that there are arm64 builds on conda-forge for python 3.8. |
|
Python 3.8.10 also added support for arm64 on macOS: https://docs.python.org/3.8/whatsnew/changelog.html#python-3-8-10-final so the arm64 ci job is trying to build a wheel for both 3.8 and 3.9 (starting 3.8 first): |
|
That is interesting. In all of my tests, all of them involved python 3.9 because I was not aware of the added support for Python 3.8. I'll trying building for that as well. Let me know if there's anything in particular that you would like me to test. I could even try doing a cross-compilation build because I can set up conda environments that are built for either architecture. (i.e. try and build and arm64 wheel in an x86 environment running rosetta 2.) |
|
The build for python 3.8.11 seems to work fine. I'll play around a bit with trying to build an arm64 wheel from an x86 Conda environment. |
|
It looks like Conan has published instructions for how to cross-compile to M1 specifically: https://blog.conan.io/2021/09/21/m1.html I've only started to read through this, so I don't know if the information in this blog will be helpful. I just thought I would post the link here just incase it turns out to have helpful information that someone else could take advantage of because I'm not sure when I'll have time to investigate this further. |
|
Hello Everyone,
#Edit_File --> 'qiskit-aer/cmake/conan_utils.cmake' %brew install libomp #BuildWheel #####_InstallWheel-->(Not sure about these two lines also.) 3.Build and Install qiskit-ignis, qiskit-aqua, and qiskit-imbq-provider following remaining instructions at: Any Feedback on clarifying some of the results in the method procedure to successfully building and installing qiskit on M1 Mac would be of great assitance! Thanks for your help! |
|
Hi! It's not completely clear to me from your post which steps you are stuck on. I think throughout the course of this discussion we figured out different ways to get Aer to build correctly, which probably makes it less straightforward to follow. Furthermore the last few posts pertain to cross-compilation using CI wheel build, which is relevant to the Qiskit team who have to automate the wheel-build process to publish binaries on pypi, but is not relevant if you are trying to build for M1 on an M1 machine since that is not cross-compilation. Here I will try to compile the relevant parts of the discussion into a straightforward set of steps that one should be able to get Aer to build successfully if they follow them. I will also try to elaborate on certain steps a bit more. My goal is to try and be as specific as possible so people with a wide range of experience levels should not have much problem following it.
needs to be changed to:
needs to be changed to: If I remember correctly (It's been a while, so hopefully this is correct.) this should be all you need to do as far as editing source code files is concerned.
and this should install Aer native for M1. You can verify that everything has been done correctly by running any Qiskit code which utilizes Aer by opening the Activity Monitor app that comes pre-installed on every Mac. It should say "Apple" under the "Kind" column next to the process that corresponds to the python program. If it says "Intel", then something because that indicates that it's running non-natively through Rosetta 2. Let me know if this works or if there are some steps which are still not quite clear. |
|
Thank you so much for your detailed response. That was the solution that I had filtered out of reading everything above with the other newly added guide on the Qiskit documentation for building from source: (https://qiskit.org/documentation/getting_started.html) |
|
Hello! I tried it with python 3.8 and 3.9. I understand, that this may have something to do with C++ libraries as discussed there, |
|
@PhilipHierhager That could be a number of things, but in my experience that is the bug that shows up when a version of llvm-openmp less than 12.0.1 is being used (thus why step 5 given above is necessary). For versions of llvm-openmp older than this, for some reason Conan builds for x86 under the covers rather than arm64, which results in the issues you are experiencing when you try to import modules in Aer. Are you using source code obtained from the main GitHub branch or the .tar.gz file from pypi? NOTE: It looks like a lot of the manual file changes given in the steps above have been merged to the main GitHub branch. It is possible that pip installing straight from the GitHub branch (so long as you have all the build dependencies installed) should work, but this is something I will have to test myself. EDIT: I tried this today and it worked for me. Instead of doing all of the manual file changes given above, you can run |
|
Thank you very much for the detailed answer! I was using the GitHub Branch and now I tried it again with your edit. I created a new environment with python 3.10 (I also tried 3.8), installed requirements with |
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 is it now published to qiskit-aer version 0.10.2 ? |
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
EDIT NOTE: For anyone coming here for step-by-step instructions on how to get Aer to build properly, skip to end of discussion. (About 45 comments down.) Running
pip install "git+https://github.com/Qiskit/qiskit-aer.git"also seems to work now with the latest GitHub main branch.Informations
What is the current behavior?
It's quite possible that this is due to a mistake on my end, but either way I would like to know what is responsible for this error and how it can be remedied. Attempting to run the following snippet of code results in the following ImportError for installations of Aer built from source for MacOS arm64:
Steps to reproduce the problem
Initialize a conda environment native to MacOS arm64 by running the following terminal commands:
CONDA_SUBDIR=osx-arm64 conda create -n <env-name> numpy -c conda-forgeNext, run:
conda env config vars set CONDA_SUBDIR=osx-arm64Deactivate the environment and reactivate it.
conda install scipy -c conda-forgepip install qiskit-aerThen just run the snippet of code. NOTE: It took me quite a few attempts to even get to the point where Aer would build. It's quite possible that in my latest attempt that resulted in the ImportError, running
pip install qiskit-aerused some cached dependency installations from previous attempts and thus this list of instructions could be incomplete. Generally speaking, if a dependency package doesn't build using pip, I runconda install <package-name> -c conda-forgeand trypip install qiskit-aeragain.What is the expected behavior?
No ImportError.
Suggested solutions
The text was updated successfully, but these errors were encountered: