-
-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Apple Silicon builds #34
Comments
FWIW, I have slycot working on my Mac M1. I'm pretty sure I just did a standard install (via conda) and it worked (presumably via Rosetta). |
Tried it again with no luck. Standard 64-bit Anaconda (presumably running under Rosetta2). For now I'd be happy with just running under Rosetta2. After installing Anaconda using the graphical installer, the following happens:
(.. wait for awhile lots of conflicts reported, after which control and slycot still don't import) |
@sawyerbfuller Slycot has now been rebuilt to include an ARM version. Can you try it out and see if it is working now? |
Hi @murrayrm thanks for letting me know. Installation of slycot seems to have worked using the installation shell script provided at the top of the page here: https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/ and subsequent installation using conda-forge. Related:
|
Ah the control-feedstock is missing the osx migrator PR. |
..,which is actually dumb because control is pure python and should be a noarch package ... |
@sawyerbfuller conda-forge now has a platform independent control package: https://anaconda.org/conda-forge/control/files Does that work for you? |
Installs! There is a wrinkle:
|
Here is printout from the install procedure:
|
Does the segmentation fault also occur with |
Good point. Looks like it's slycot:
|
I am not sure if I understand this statement. Did you compile it yourself or did you use the package from conda-forge? |
@bnavigator my apologies for the incorrect wording.
|
Hmm, seems like the conda-forge compiled slycot package is broken then. For testing, I would recommend cleaning your Are you able to step through a debugger or inspect the stack trace at the segmentation fault? |
I tried installing on my Mac (MacOS 12.1, M1 Macbook Air) and it worked OK, but I can't tell if I am running the arm64 version of the non-ARM version (with Rosetta2). Specific sequence that worked:
For me, there is a pretty long delay (15 seconds) before the version for control prints, which is often an indication that Rosetta is doing translation. Printing the version for slycot is instantaneous. |
@murrayrm the delay would come because control imports slycot. The second call then uses the already translated slycot. Can you try without importing control first? I guess you would see the used package in the name of the egg-info directory. Check
Also (on my linux system):
|
Indeed, I am getting slycot-0.4.0.0-py3.9-macosx-10.9-x86_64.egg-info |
FWIW, the closest I can get to mimicking this is on my aarch64 Helios 64. I
tried the following:
- install Miniforge: https://github.com/conda-forge/miniforge/#download
- install control with conda install control
- I installed conda-build, and then built slycot with the recipe from
slycot-feedstock
- uploaded that to my anaconda account, and then installed from there
"import slycot" in Python then simply works.
Can you check linking requirements on the wrapper with
otool -L _wrapper.cpython-39-darwin.so
??
On my Intel-based mac (I know it needs updating), it produces:
(base) TUD500083:slycot repa$ otool -L _wrapper.cpython-37m-darwin.so
_wrapper.cpython-37m-darwin.so:
@rpath/liblapack.3.dylib (compatibility version 0.0.0, current version
0.0.0)
@rpath/libblas.3.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libgfortran.5.dylib (compatibility version 6.0.0, current version
6.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
1197.1.1)
…On Thu, 6 Jan 2022 at 15:46, Richard Murray ***@***.***> wrote:
Indeed, I am getting slycot-0.4.0.0-py3.9-macosx-10.9-x86_64.egg-info
—
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVKIDPT5GX3ARFSZYFEN6LUUWTKXANCNFSM5HWREXSA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
René van Paassen | ______o____/_| ***@***.***
<[___\_\_-----< t: +31 15 2628685
| o' mobile: +31 6 39846891
|
@bnavigator Debugging slycot binary is probably beyond my abilities/time availability. I will keep fiddling to see if I can get things to work under Rosetta2 (no idea why that doesn't work for me) |
Update: I am back to running anaconda using Rosetta2 (osx-64). When I created a new environment, slycot and control installed their own dependencies and ran successfully. So it looks like the problem is a conflict between the default osx-64 anaconda distribution and slycot. One question: right now control depends on installing slycot (see below) but given that slycot has more constrained depencies, and a lot of control can work without it, have we considered removing it as a dependency?
|
If/when we get this right, there should be no problem having control depend on slycot in terms of conda/conda-forge: they will both be available on all of the same platforms. And there is some advantage, I think, in just having to do one install and getting all of the dependencies. Note that there are still quite a few important things that won't work without slycot. Many operations won't work without slycot: state space realizations of a transfer function, any type of Hinf synthesis, balanced truncations. |
I created a conda environment using arm64 using the following command
When I install Output from otool -L _wrapper.cpython-39-darwin.so (@repagh request)
Running with
Backtrace:
Walking up through the backtrace just shows assembly code, so not very useful. |
Thanks @isuruf! So does your fix in conda-forge/python-blosc-feedstock#39 work? Can we do the same here? |
@murrayrm, do you still get the segfault when you execute
? |
New error:
|
|
Ran that:
|
Okay, so the link is actually necessary. Could you try:
|
I'm not getting a libpython3.9.dylib as a shared library for python:
??? |
The latest build (from PR #47) appears to be working correctly (!). @sawyerbfuller Can you give this is a try when you have a chance? @isuruf Thank you for all of the help! |
@murrayrm It seems I'm having trouble installing the osx-arm64 version of slycot (looks like I'm still getting osx-64 versions of related package like libblas, which I assume is not what I want):
The commands leading up to this followed what you typed in above, and were executed on a standard anaconda installation. It looks like other other packages that were being installed are arm native:
|
@sawyerbfuller I had that problem as well. You need to set the environment variable
|
@murrayrm That seems to do the trick. I was able to install slycot and then and run some code from it. That is, assuming after all that that the arm64 version of slycot was the one that was imported. |
Here's the commands that I ran to convince myself I was running the ARM version:
I think the arm64 at the end is the key: this says that you are on an M1 Mac. Otherwise, you get x86_64. |
Ok looks good, thanks!
|
Done. Thanks @bnavigator, @repagh, and @sawyerbfuller for the comments and feedback and @isuruf for the final tricks to implement (in PR #47). |
@sawyerbfuller mentions in python-control/python-control#670 (comment) that he can't get Slycot on his Mac M1. The files on conda-forge are over 1 year old. I guess the procedure described here needs to be executed:
https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/
The text was updated successfully, but these errors were encountered: