Build does not work on Apple M1 Chip #409
Comments
|
I raised an upstream issue |
Kethku
added
upstream
|
@reisub0 could you try compiling and running the skulpin examples and see if you run into the same issue? |
|
Hey @Kethku. I tried to run the physics example for Please let me know I should run some specific example or commands. |
|
Hi, I think we do have a branch of skia-bindings and skia-safe that builds on an aarch64-apple-darwin host (Cross compiling fails at the linking step, which I've to investigate why). So to anyone interested, check out the m88 branch and try build it on your new Mac. If that succeeds, we can work our way up to porting Skulpin and then Neovide to the Skia M88 API surface and hopefully release matching Skia binaries soon. |
|
@pragmatrix thanks so much for pointer! I'm hoping to have access to an M1 mac in the not too distant future so I can start debugging this as well |
|
What files would I need to change in order to use the m88 branch of rust-skia? |
|
An update here regarding rust-skia: The current release (m90) of rust-skia builds on M1 macs and cross-compiles and links successfully with |
|
running |
|
Never mind, upgrading skis-safe to v0.39.1 worked. In case anyone else needs it, here is the .app file generated using the openGL branch: https://drive.google.com/file/d/1ASziUDhskTqAfrADDnS-dBTnRNQDJaTO/view?usp=sharing (you only need the .app file, not sure why it uploaded like that) |
|
I apologize for the permissions issue. You should be able to view and download the build without having to request now. |
|
@shaunsingh so are current builds in the github pipeline working properly? If not does this issue need to change to track adding support for m1 macs to the pipeline? What work is remaining here? |
|
@Kethku At the moment cloning the repo and building the repo manually will work fine, however it won't work in GitHub actions, since CI support for macOS 11 is still in beta. For now if you want to build the app for apple silicon you would have to do it manually. There isn't any work remaining, and it should be plug and play once Github updates their CI infrastructure in June/July of this year. You can close the issue if you would like, I can manually provide builds when needed for now |
|
I'm still getting winit-0.22.2 errors. One example: |
|
That feels like either an upstream or rust version issue. |
|
@restfuladi Are you building the openGL or Vulkan build? I built the OpenGL one this morning I just uploaded it here: https://drive.google.com/file/d/1ASziUDhskTqAfrADDnS-dBTnRNQDJaTO/view?usp=sharing |
|
@shaunsingh I appreciate that you are trying to help, but please refrain
from sharing binaries on from separate source. No one knows what could be
in that binary. That's how you get viruses.
…On Thu, May 20, 2021, 11:58 AM shaunsingh ***@***.***> wrote:
@restfuladi <https://github.com/restfuladi> Are you building the openGL
or Vulkan build? I built the OpenGL one this morning
I just uploaded it here:
https://drive.google.com/file/d/1ASziUDhskTqAfrADDnS-dBTnRNQDJaTO/view?usp=sharing
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#409 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6S7P6S3FFBRMVEYAAVQNDTOVLTRANCNFSM4U2JTHVQ>
.
|
|
However, I built it myself just this morning. I can assure you there are no viruses |
|
I think its reasonable to post a test binary. But @j4qfrost is right, downloading and running it does incur some risk. The ideal solution would be to automatically build these via the ci system, but as mentioned above, m1 builds aren't supported currently. @restfuladi download and run at your own risk |
|
@shaunsingh sorry didn't mean to be accusatory. Also I messed up my grammar. It is a good practice to share builds created by the CI, because it is backed with more trust. If we make a habit of sharing binaries from sources that we can't validate, then a malicious person could come in and since everyone has become comfortable downloading binaries from anyone, they will run one without question. This is especially true of newcomers to the project. |
|
I definitely agree. Sadly GitHub Cl for Big Sur is delayed, but once it comes it would be a much better solution. Another thing I've been wondering about, is it possible to build a universal build using rust? Right now if you run it on an arm machine, it will produce an arm build, but can you do an intel build from arm and vice versa? I'm not sure whether the new Cl is arm or intel based, but that would be a big issue |
Vulkan, with latest SDK installed. OpenGL builds successfully. |
|
I would recommend sticking to openGL regardless. It seems to perform much better and doesn't have the HiDPI scaling issue |
|
@shaunsingh it should be possible with a docker solution, but there will be headaches trying to get everything working. Not sure if something like M1 builds on docker would be hardware dependent. |
|
rust-lang/cargo#8875, looks like its in progress right now. Doesn't seem like there is an easy way to do it, its going to be a headache for sure |
|
I'm hoping to eventually get enough sponsors to purchase an m1 device for the project. So if an upstream solution doesn't arrive, that might work instead longer term. (note: I will probably purchase one eventually regardless, but I've been setting aside the money from kofi and now the github sponsors for this purpose so that we can have a solution for M1 binaries as well as just better support for the platform in general) |
|
@Kethku Using an on demand Scaleway instance for M1 might be feasible. We
could get some other projects together and pool resources to rent them out.
There's a minimum of 24 hours before you can shut them down.
…On Thu, May 20, 2021, 12:53 PM Keith Simmons ***@***.***> wrote:
I'm hoping to eventually get enough sponsors to purchase an m1 device for
the project. So if an upstream solution doesn't arrive, that might work
instead longer term.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#409 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA6S7P4YYXFOJFYG4ORHDVTTOVSDRANCNFSM4U2JTHVQ>
.
|
|
actions/runner-images#2486 (comment), looks like GitHub is starting to roll the macOS 11 machines out. |
|
@shaunsingh I don't see where this is the case in that issue. Looks like they're just upgrading the macoa version. |
|
Yup, I just reread the issue looks like its just an OS upgrade. Regardless, its what we need for automated M1 builds (with GitHub CI at least) The only other decision to make is do we want to provide a fat (universal) binary or individual builds for intel and arm? I believe you can produce the two binaries and link them together with |
|
@j4qfrost what are the chances we could get something like this: https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners working on the m1? |
|
|
|
actions/runner#805 (comment) I guess theres a work around 👀 |
|
Just capturing some more docs: https://gregmfoster.medium.com/using-m1-mac-minis-to-power-our-github-actions-ios-ci-540c55af13ea |
I had a look at this. Will get to work this weekend to see if we can get this on the M1. |
|
Does anyone have an m1 machine they can use for the actions though? From what I understand you would need a machine dedicated to running actions |
|
We recently acquired some M1 hardware :) |
|
A lot of the hard work was already done on rust's side, I just had to set things up. #711 @pragmatrix let me know if you want to set up a self-hosted M1 machine for your Azure pipeline. |
|
@j4qfrost Thank you a lot for the offer. But if this does not block Neovide (or someone else cries out loud), I'd prefer to cross-compile rust-skia binaries from Big Sur Intel images as soon they are available. |
|
M1 runner is now live and building an arm64 binary uploaded as Neovide-m1.dmg. I think that should close out this ticket. |
|
May I ask where to find this Neovide-m1.dmg? |
|
The current release neovide.dmg here is a universal binary (which means that it is optimized for both M1 and Intel Macs) |
|
I installed neovide using the link suggested: open the dmg file and drag the neovide app to Application. However, nothing showed up after I run the app by double clicking it. Have I missed anything important here? Such as, installing Rust related stuff? |
|
That's a bit strange. You do not need to install anything extra. It's a package. The only possibility I can think of is that you may need to add an exception for it with macOS' Gatekeeper |
|
Thanks. However, I'm still unable to get neovide running after allow it to "run anyway" as suggested. I also tried the instruction to install neovide through Homebrew, i.e. I then tried to follow the instruction to build neovide from the source. However, I go the following errors after running
... I don't know Rust and Cargo at all. So, hope expert here can advise me what important steps I have missed. Thanks. |
|
Trying to build may not necessarily help, it's going to output the same release file that you're anyway not able to run (either through Can you take a look at the console logs by opening |
|
Thanks. There is no crash report in the I'm attaching the screenshots of the steps I went through below.
|
|
Another thing to look at would be to look at the streaming logs on console.app and see if you can find any clues there. I think it might be best if you open a new issue for this. After allowing it through Gatekeeper, the build (and the Cask) works completely fine on my MacBook Pro M1, so it doesn't seem to be an issue with the build itself, and seems to be idiosyncratic to your environment. |
|
Noted. I'll open a new issue if I can't find a solution. Btw, I like NeoVide very much which is running perfectly on my Windows computer. Thanks to the NeoVide dev team. |
When building with
cargo build --release, I get the following errorThe text was updated successfully, but these errors were encountered: