-
Notifications
You must be signed in to change notification settings - Fork 213
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 M1 build. #337
Comments
Blocked by actions/runner-images#2187 |
Since the mvnd is written in Java, we could provide a jvm based distribute as a universal version. |
That exists already. Download whichever build and use |
I have changed the homebrew install scripts for using the |
The PR for the home-brew recipe has been merged. |
BTW, this GraalVM issue states that native executables for mac x86_64 are runnable on Apple silicon using Rosetta Translation Environment It would be interesting to compare the speed of the translated binary with mvnd.sh + JVM. BTW, isn't the JVM on Mac AArch64 also just a Rosetta translation? |
Reopening, because we want a Mac@AArch64 build when all the parts are available. This is also blocked by oracle/graal#2666 |
There is also jansi
|
This would require a fix for multiarch/crossbuild#51 so that jansi could have a M1 version. |
I was able to run JAVA_HOME=/tmp/zulu16.32.15-ca-jdk16.0.2-macosx_x64 mvnd clean install -DskipTests However, even after the daemon was warmed up, it was still slower than running |
I think we can close this as it was fixed in #502. I’ve been happily using the 0.7.0 release successfully on my M1 Mac mini! |
I am on M1 and mvnd 0.7.0 works there. |
Well, it works, but it's still using the Apples' Rosetta 2 translation layer. I'd rather keep that one opened until GraalVM supports M1 directly. |
There is some update in oracle/graal#2666 (comment)
but it is not clear to me whether the changes are released already and which release it is. |
This comment oracle/graal#2666 (comment) states
This would make it at least possible to compile locally on a darwin-aarch64 machine. |
I am trying it to see how it goes 🤞 |
@ppalaga it built fine. I tried building Camel with it (cached) and it went fine. Performance was nice too (10 core M1 Pro building it roughly with the same duration as a Ryzen 9 3900XT). |
I know support is not official yet, but sharing my experience in the hope it will eventually be useful for when there is an official release. One thing I noticed is that the build for ARM doesn't seem to respect the |
A new issue for OSX arm64 runners hosted by GitHub was recently added to GH public roadmap: github/roadmap#528 I think this issue won't move without that one. |
Citing from actions/runner-images#2187 (comment)
|
Ouch, that's quite a long time. I'm wondering if it would be feasible to provide |
AFAIK, Homebrew doesn't provide a build service. They have manifests (in fact, Ruby files) that describe how to download (and optionally build) software on the users machine. |
Yeah, that's what I was thinking of (sorry, I did not explain it well). Just have it build on the user's computer with the help of brew. |
I am still waiting for this on M1, doing a build from source on M1 will help or I need to wait for official release? |
@orpiske 's script is still be the best way to get a working native |
Unfortunately, Java 8 (Temurin Open JDK) fails with the following: JAVA_HOME is not set. Setting JAVA_HOME to the location of your Java installation.
JAVA_HOME is set to /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home.
Using 'mvnd' to build workload.
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/mvndaemon/mvnd/client/DefaultClient has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)
make: *** [compile] Error 1 |
@mprimeaux for running mvnd.sh with Java 8, please see #669 (comment) and #547 (comment) |
@mprimeaux Also, a candidate release of |
How were those M1 builds produced, @gnodet ? |
On a Mac mini M1 that MacStadium has freely provided to me for the maven project. |
@gnodet |
I've just tested the 0.8.2 build with Camel and it works nicely! |
It seems the brew formula for mvnd was updated to Oddly, however, I'm still receiving the same exception as before after installing the updated version. ❯ brew list mvnd ─╯
/opt/homebrew/Cellar/mvnd/0.8.2/bin/mvnd
/opt/homebrew/Cellar/mvnd/0.8.2/bin/mvnd-bash-completion.bash
/opt/homebrew/Cellar/mvnd/0.8.2/libexec/bin/ (2 files)
/opt/homebrew/Cellar/mvnd/0.8.2/libexec/conf/ (3 files)
/opt/homebrew/Cellar/mvnd/0.8.2/libexec/mvn/ (85 files) Against the Temurin 8 JDK: ❯ mvnd --version ─╯
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/mvndaemon/mvnd/client/DefaultClient has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601) I decided to downloaded version 0.8.2 again and test as per @gnodet here and this version works great against the same Java 8 source that failed above. I'm not yet sure what's going on but thought I'd post it here before I investigate. |
When I released 0.8.2, i used the usual formula which had not been updated wrt to the new M1 binaries. I think you still have the |
Yes. Let me try that now. UPDATED: Uninstalling and reinstalling worked. Thanks again! |
مشكورر |
@gnodet i tested the universe binary combining two archs of amd64 and arm64 on macos, the result binary works well on intel mac, and should work as well on arm mac. the zip file size is increased from 20M to 29M. how about releasing the universe native binary for macos? |
That would remove a specific platform and ease releases as the M1 builds have to be done and uploaded manually. How do we tell graalvm to build a universal binary ? |
@gnodet lipo -create -output /path/to/universe/binary/mvnd maven-mvnd-1.0-m6-m39-darwin-{amd64,aarch64}/bin/mvnd and repack zip at last. This process still requires a special environment to build the M1 binary and combine a universe macos distribution. |
This makes the release process even more complicated. What's the real benefit ? |
yes, the release process need to do some little refactor. with this feature, the macos developer can more easily select the correct distribution file. |
As per actions/runner-images#8439
So we could extend our testing and release matrix to include |
When reading actions/runner-images#8439 properly, it looks like the named images are not yet a part of the GHA free tier. |
@ppalaga You can try FlyCI's M1 and M2 runners. They are on average 2x faster and 2x cheaper than GitHub's AND we have a free tier for OSS projects (see below). Install Instructions
jobs:
ci:
- runs-on: macos-latest
+ runs-on: flyci-macos-large-latest-m1
steps:
- name: 👀 Checkout repo
uses: actions/checkout@v4 500 mins/month Free for Public ReposSince your repo is public, FlyCI offers 500 mins/month of free M1 runner usage with the Don't hesitate to contact us in case the free tier doesn't suit your needs or you experience any issues with the runners. Our team is here to support you! Best Regards, |
MacOS binaries are now provided since #1027 |
No description provided.
The text was updated successfully, but these errors were encountered: