-
Notifications
You must be signed in to change notification settings - Fork 25
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 (arm64) support #75
Comments
Any news on this one? |
Built with patch for TheInfiniteKind/appbundler#75
@sreilly I'd be happy to hire The Infinite Kind staff to work on arm64 support for appbundler. |
Completely based on TheInfiniteKind#75
@sreilly I know what it's like not having any time. I've made a PR that might make it a little easier to close off this issue. |
I have a weird situation regarding M1 support for my Java app that I hope people can help figure out. I just downloaded and built a fresh copy of appbundler. Using it in my Java build process, I find that it does build a fat Java launcher for my app. However, the app still fails to launch and displays the "please install Java" dialog. I added some extra diagnostics to main.m, and it reports that
In other words, even though the Java launcher is fat, it seems to be using the x86_64 code, which doesn't like the arm64 libjli.dylib in my Azul Zulu Java 17 install. Even more confusingly, one of my app users says that the app is launching for him on an M1 Mac with an arm64 Azul Zulu Java 17. Any ideas? I have determined that if I build a skinny appbundler which is arm64 only, my app will launch on this M1 Mac. |
Hi rschmunk, how do you build fat instead skinny. I am currently having to one build on Intel Mac and one on M1 Mac to provide two skinny dmgs, with the user having to make sure they pick the right one. |
@false, I downloaded the latest version of the code and simply built it as is on an M1 Mac. Using the |
What do you pass as parameter to lipo i cant get it to work |
You can check the universal status of the launcher using the file command. From within the top level of the .app bundle folder:
The problem is that all of the .dylib libraries that form the jvm also need to be fat binaries. I don't think this is the case with any of the prebuilt [open]jdk distributions. There is a lipo command you can run that will combine x86_64 and arm64 dylibs (from here):
You'll need to run a script to do that, combining an x86_64 and arm64 jvm. Beyond that you'll also probably need to unpack any .so/.dylib files from jars that contain native code to do the same. Hopefully all of the jar-embedded libraries contain both architectures too. I don't know what other problems might stand in the way, but this would at least be some progress. I guess the end goal is to have pre-built mac openjdks that are already universal. |
OK rschmunk running file shows that main application is universal, but of course the Java runtime it is using is not as I only create a jre for the platform I am running on, so maybe this is what you are seeing @sreilly my knowledge of this is very limited but I was just hoping that a solution would be to allow two instances of jlink in the appbundler task and one could be used to generate M1 and one to generate Intel since you dont need to be on the platform to generate the runtime (e.g on my Windows PC I use the jlink command directly to create both Windows Jre from Windows Jdk and Linux jre from Linux jdk). So the bundled app would just contain two Java runtimes in the PlugIns folder and then the main application created would be able to automatically select the correct one based on its cpu. |
cd into your app package's Contents/MacOS directory and run
or as @sreilly suggests
|
Surely someone has worked around the problem by now. What are the methods of changing this project's code that would allow it to work better? |
I have solved this with a script that uses the lipo command to combine two JREs that I generate using jlink. I have another script in which I run jlink on adoptium JDKs to generate directories for each platform's JRE bundle. The result of that script is a directory for each jvm, including jvm-mac and jvm-macarm. The next step is running the following script to combine them into a jvm-universal directory:
I then use appbundler to make an app bundle with the jvm-universal JRE. This has worked in my limited testing so far. I haven't yet released an app that uses this bundle, but I hope to do so soon. |
Actually, this issue is solved in this project. |
Completely based on TheInfiniteKind#75
Symptom
getting a non-descriptive
error: JRELoadError
message on Apple M1Problem
with some extra debugging, it clearly shows the failure is due to arch mismatch:
But the current build is locked and forced to
x86_64
only:Solution
requires a bit more nicer one but as a proof of concept, this one worked for me:
the binary does show support for both architectures and starts an app just fine:
The text was updated successfully, but these errors were encountered: