![]() # Not a file with binary code, copy it as it isĬp $arm_file jvm-macuniversal/$noarch_file Lipo -create -output jvm-macuniversal/$noarch_file jvm-mac/$noarch_file $arm_file # Create universal binary from both x86_64 and arm64 If file $arm_file | grep "Mach-O.\+arm64" then || die "Missing arm64 JRE"įind jvm-macarm -type f | while read arm_file do # Script to combine an intel and arm64 JDK into a single universal JDK I guess the end goal is to have pre-built mac openjdks that are already universal. I don't know what other problems might stand in the way, but this would at least be some progress. Hopefully all of the jar-embedded libraries contain both architectures too. so/.dylib files from jars that contain native code to do the same. Beyond that you'll also probably need to unpack any. You'll need to run a script to do that, combining an x86_64 and arm64 jvm. Lipo lib1.dylib lib2.dylib -output combined.dylib -create There is a lipo command you can run that will combine x86_64 and arm64 dylibs ( from here): I don't think this is the case with any of the prebuilt jdk distributions. dylib libraries that form the jvm also need to be fat binaries. Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64Ĭontents/MacOS/Moneydance (for architecture x86_64): Mach-O 64-bit executable x86_64Ĭontents/MacOS/Moneydance (for architecture arm64): Mach-O 64-bit executable arm64 I have determined that if I build a skinny appbundler which is arm64 only, my app will launch on this M1 Mac.Ĭontents/MacOS/Moneydance: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64 ![]() 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.Įven 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. 22:54:42.916520-0400 MyApp int launch(char *, int, char **) dlopen failed: dlopen(/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/lib/libjli.dylib, 0x0001): tried: '/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/lib/libjli.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/lib/libjli.dylib' (no such file) I added some extra diagnostics to main.m, and it reports that However, the app still fails to launch and displays the "please install Java" dialog. ![]() ![]() Using it in my Java build process, I find that it does build a fat Java launcher for my app. I just downloaded and built a fresh copy of appbundler. I have a weird situation regarding M1 support for my Java app that I hope people can help figure out. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |