Skip to content
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

Apple Silicon support #2181

Closed
deepj opened this issue Dec 7, 2020 · 32 comments · Fixed by #2657
Closed

Apple Silicon support #2181

deepj opened this issue Dec 7, 2020 · 32 comments · Fixed by #2657
Assignees
Labels
Milestone

Comments

@deepj
Copy link

@deepj deepj commented Dec 7, 2020

I've just received Macbook Air with M1 as a replacement for my half-broken old Macbook Pro with Intel i5 what became very slow thanks to the bazillion security fixes for the Intel chip.

I tried to run TruffleRuby (2.1.0.0-dev) on the new Macbook and so far, so good. It's running under Rosetta 2 very well. I haven't noticed any issues yet.

So my question is, when we can expect TruffleRuby for Apple Sillicon builds? 🤓

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Dec 7, 2020

Blocked by oracle/graal#2666.

I'm afraid this issue needs some expert attention by the people who manage things like JVMCI and JVM builds - this is really specialised stuff needing the Oracle build farm I think and I'm not able to do it myself.

@eregon eregon added the macos label Dec 8, 2020
@eregon
Copy link
Member

@eregon eregon commented Dec 8, 2020

Regarding builds on darwin-aarch64:

  • GraalVM release builds: we need oracle/graal#2666
  • nightly builds: the above + GitHub Actions would need to support darwin-aarch64.

Until that's done I guess using Rosetta 2 is the best solution for running TruffleRuby on Apple's M1.

@deepj
Copy link
Author

@deepj deepj commented Dec 9, 2020

@chrisseaton @eregon thanks both for the answers

In fact, it's already possible to build for Mac ARMs using Github Actions on the recent Mac x86_64 machines since Xcode 12.2. Already this project (https://github.com/keeweb/keeweb/releases) builds own ARM Mac builds using GA.

On GA there aren't available any Apple Silicon machines for testing builds on them though. You build own releases and test them on own bare metal machines anyway.

@eregon
Copy link
Member

@eregon eregon commented Dec 10, 2020

I think we'd want to have automated testing in CI before making darwin-aarch64 builds.
For instance I'm thinking for Ruby installers we should probably still pick the darwin-amd64 builds until the darwin-aarch64 builds are strictly better.

@deepj
Copy link
Author

@deepj deepj commented Jan 2, 2021

@eregon After almost a month spend with M1 I don't think that is a good way. It requires to use seperated Homebrew for x86_64. I already switch to Homebrew for ARM only since over 70 % of bottles are already ARM ready.

Homebrew doesn't support something like universal builds. That complicates many things while compiling 3rd dependencies. Keeping two separated Homebrew is not also easy. Just take a look at ruby-build issues with trying to build Ruby for ARM. Some people has a problem to understand they are mixing x86x_64 stuff with ARM's one.

@eregon
Copy link
Member

@eregon eregon commented Jan 2, 2021

Thanks for the update.
It seems the only way for now until oracle/graal#2666 is fixed and Sulong supports ARM64.

Why does it require a separate Homebrew? To install libssl?
If so, shipping TruffleRuby with libssl might be a solution.

I've seen many issues from M1 users e.g. on the FFI gem issues, it seems there is confusion, but probably some of that should be handled better by Homebrew or Apple.
My personal opinion is M1 users need to lean about some of these complications, because we cannot expect every OSS maintainer has time to port software for M1 and even has an M1 processor to test this new architecture+OS combo.
For TruffleRuby, I think we will support running on M1 natively at some point, but it will take some time.

@deepj
Copy link
Author

@deepj deepj commented Jan 13, 2021

@eregon Yes, the main problem is OpenSSL from Homebrew for ARM. What I remember some issues were with ARM version of PostgreSQL, pg gem and TruffleRuby (no issue under ARM version of MRI).

I understand your points. But I guess this is not only about Apple M1, I feel it's more about benefiting other ARM based CPUs generally. The changes for Apple M1 bring better SW compability e.g. for Rasberry computer. TruffleRuby/GraalVM cannot be run e.g. on Rasberry Pi yet.

@deepj
Copy link
Author

@deepj deepj commented Feb 5, 2021

@eregon Hello, is there any internal news if some basic support of Apple ARM's will be landed soon into GraalVM/Sulong?

@eregon
Copy link
Member

@eregon eregon commented Feb 5, 2021

@deepj See oracle/graal#2666 (comment), nothing can happen until upstream JDK supports darwin-arm64.

@eregon
Copy link
Member

@eregon eregon commented Feb 5, 2021

FWIW, linux-aarch64 is another story, for that case there are already JDK11 builds for it, and TruffleRuby can already be built there (but Sulong does not work yet on linux-aarch64).

@deepj
Copy link
Author

@deepj deepj commented Mar 12, 2021

@eregon it seems Apple ARM support in OpenJDK (openjdk/jdk#2200) will be landed soon. I guess there will be some work on Graal side. Is any chance to offer some experimental builds of TruffleRuby with Apple ARM support? I want to really avoid any compilation of Graal/TruffleRuby on my system.

Of course, you have other priorities. I'm just asking :)

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Mar 12, 2021

I hope to get an M1 laptop when Apple take away my DTK, so may go back to working on this.

@eregon
Copy link
Member

@eregon eregon commented Mar 12, 2021

Once there are labsjdk JVMCI builds (oracle/graal#2666), we can look at this and share an experimental build.
We'll also need Sulong to support darwin-arm64 for C extensions, for which the related linux-arm64 support is I think in progress.

@deepj
Copy link
Author

@deepj deepj commented Mar 25, 2021

Support of Apple ARM's has been merged into OpenJDK (just sayin')

@deepj
Copy link
Author

@deepj deepj commented Apr 9, 2021

@eregon Hm, is there any internal progress in Graal to support Apple ARM since OpenJDK has it already?

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Apr 9, 2021

We're still blocked by oracle/graal#2666. Might be best to ask there until that issue is fixed.

@deepj
Copy link
Author

@deepj deepj commented Sep 20, 2021

Any news

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Sep 20, 2021

As it says above, we're still blocked by oracle/graal#2666.

That's the blocker. That's where you need to ask for progress.

We really appreciate your enthusiasm, but we can't do anything ourselves.

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Dec 5, 2021

To build and run using Rosetta on an M1 machine:

  • Create a copy of Terminal, open properties, and set it to open using Rosetta
  • Using this Terminal:
  • Install Homebrew (again, if you've already installed it, it'll go into /usr/local/homebrew this time)
  • Don't forget to now use eval "$(/usr/local/homebrew/bin/brew shellenv)" instead of what you had before
  • Install cmake and openssl@1.1 (not just openssl)
  • Build and run as normal

@nirvdrum
Copy link
Collaborator

@nirvdrum nirvdrum commented Dec 8, 2021

Thanks, @chrisseaton. Those steps were very helpful. To simplify the correct Homebrew installation loading, you can use uname -m to get the current architecture. It'll be arm64 in native M1 mode and x86_64 when run in Rosetta. I've changed my shell startup to look like this:

if [ (uname -m) = "arm64" ]
  eval (/opt/homebrew/bin/brew shellenv)
else
  eval (/usr/local/homebrew/bin/brew shellenv)
end

That implies that you installed Homebrew for M1 first. If you did it the other way around, just swap the branches (or the condition). That's for the fish shell. The same basic idea should work for your shell of choice.

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented Dec 8, 2021

if [[ $CPUTYPE == arm64 ]]
then
    eval "$(/opt/homebrew/bin/brew shellenv)"
else
    eval "$(/usr/local/homebrew/bin/brew shellenv)"
fi

@nirvdrum
Copy link
Collaborator

@nirvdrum nirvdrum commented Dec 8, 2021

Not having to invoke another process would be preferable, but that $CPUTYPE variable looks to be a zsh thing (and it doesn't show up in env output -- odd). I don't see it set in either bash or fish.

@gimbles
Copy link

@gimbles gimbles commented Feb 14, 2022

Not having to invoke another process would be preferable, but that $CPUTYPE variable looks to be a zsh thing (and it doesn't show up in env output -- odd). I don't see it set in either bash or fish.

@nirvdrum This shouldn't be that big of a problem since ZSH is the default shell for MacOS -- although to make it more portable, spawning a uname instance would be better. It's pretty cheap and won't affect much.

@nirvdrum
Copy link
Collaborator

@nirvdrum nirvdrum commented Feb 14, 2022

@Yush08 Thanks. I don't use ZSH though, thus my note.

@deepj
Copy link
Author

@deepj deepj commented Mar 22, 2022

There are dev builds of GraalVM supporting Apple Silicon.

https://github.com/graalvm/graalvm-ce-dev-builds/releases/tag/22.1.0-dev-20220321_2332

Can we see testing builds of TruffleRuby supporting Apple Silicon in near future? :)

@eregon
Copy link
Member

@eregon eregon commented Mar 22, 2022

Yes, it's being worked on by @lewurm.
What we need is Sulong and TruffleRuby support for darwin-aarch64.
A large part of the work seems va_args support for Sulong.
It doesn't make much sense to add support in TruffleRuby before that (none of the C exts would work).
For TruffleRuby it's probably quite straightforward anyway, and we'll want to add CI jobs to ensure everything works well.

@chrisseaton
Copy link
Collaborator

@chrisseaton chrisseaton commented May 11, 2022

@deepj
Copy link
Author

@deepj deepj commented May 12, 2022

Great work @chrisseaton and the others! I hope we can try nightly builds very soon. I can't wait to test TruffleRuby after so long time :)

@eregon eregon linked a pull request May 27, 2022 that will close this issue
@deepj
Copy link
Author

@deepj deepj commented May 30, 2022

Thank you! @eregon Is there any public nightly build is available?

@eregon
Copy link
Member

@eregon eregon commented May 30, 2022

We should be able to have GraalVM dev builds at https://github.com/graalvm/graalvm-ce-dev-builds, but those lag a few days up to 1-2 weeks behind due to using the truffleruby import in GraalVM. ruby-build truffleruby+graalvm-dev ~/.rubies/truffleruby+graalvm-dev will work then.

For the standalone dev builds (https://github.com/ruby/truffleruby-dev-builder), I don't see any way currently as GitHub-hosted runners are not available darwin-aarch64 (neither linux-aarch64), all of https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources is amd64 only.
Self-hosted runners would probably be a security/trust issue, unless owned and maintained by the ruby organization maybe.
We could potentially have internal truffleruby nightly standalone builds published like https://github.com/graalvm/graalvm-ce-dev-builds does but that is a significant effort.

@deepj
Copy link
Author

@deepj deepj commented Jun 3, 2022

I successfully installed a native build from https://github.com/graalvm/graalvm-ce-dev-builds on my M1 mac :)

truffleruby 22.2.0-dev-0f63df6f, like ruby 3.0.3, GraalVM CE Native [aarch64-darwin]

@eregon
Copy link
Member

@eregon eregon commented Jun 10, 2022

Darwin-aarch64 dev builds are now available via

ruby-build truffleruby-dev ~/.rubies/truffleruby-dev
# or
ruby-build truffleruby+graalvm-dev ~/.rubies/truffleruby+graalvm-dev

with rbenv/ruby-build#1980.
With the caveat it might be a build with a truffleruby commit ~1 week old.

Should probably add those builds to RVM too at some point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants