JOGL for Mac ARM Silicon

Hi,

Apparently, a first version of OpenJDK for Mac ARM is available at Azul. How difficult would it be to compile JOGL for this environment? Are there some directions that would help to try generate the required .dylib files? Any hope that they will be available for the final 2.4.0?
Thanks for your suggestions.

Hello

Have you read our build instructions?
http://forum.jogamp.com/jogl/doc/HowToBuild.html

Thanks for the instructions. They were useful and after a few changes, I was able to get a running JOGL / Java 3D application running on a Mac ARM

As instructed, I downloaded Azul OpenJDK for Java 11 and 8 (my target), installed Ant and CMake. There's no version of CMake for macOS arm64 yet but using Intel version with Rosetta 2 correctly worked.

There was no problem to compile Gluegen but the generated .dylib file was for x86_64, not arm64. Therefore, I replaced "x86_64" by "arm64" in gluegen/make/gluegen-cpptasks-base.xml file in the two following lines:

<compilerarg value="x86_64" if="use.macosx64"/> 
<linkerarg value="x86_64" if="use.macosx64"/>

and that was enough to get libgluegen_rt.dylib for arm64 architecture (info checked with "lipo" command).
I even succeed to create a "universal" .dylib file which combines both architectures with the command:

lipo libgluegen_rt-arm64.dylib libgluegen_rt-x86_64.dylib -output libgluegen_rt.dylib -create

It was a little more complicated to generate JOGL .dylib files. First, I searched in .xml files some lines similar to the ones for Gluegen architecture, and after a few failures, I realized that there was no .xml files to change for JOGL because the build process reused the compilation configuration set for Gluegen!
There was also a link to SWT that I didn't succeed to set, so I just removed the following folders where it's referenced:

jogl/src/nativewindow/classes/com/jogamp/nativewindow/swt
jogl/src/jogl/classes/com/jogamp/opengl/swt
jogl/src/newt/classes/com/jogamp/newt/swt

NEWT couldn't still be generated but as I don't need it, I just used the .dylib files that were successfully generated.

Finally, I extracted the libjogl_desktop.dylib, libnativewindow_awt.dylib and libnativewindow_macosx.dylib files needed by Java 3D, and signed the 4 .dylib files once I realized it was required to make run an arm64 application under macOS 11.
The result can be tested with the JAR executable SweetHome3D-6.4.2a-jogl-2.4.0-rc-20200307.jar which is able to run under macOS Intel or ARM, Windows and Linux.
If you want to test the universal .dylib files I generated in your own program, just extract the following files found in the java3d-1.6/macosx folder of the previous JAR executable.

libgluegen_rt.dylib
libjogl_desktop.dylib
libnativewindow_awt.dylib
libnativewindow_macosx.dylib

The Gluegen / JOGL JAR files and DLLs for other systems come from the version 2.4.0-rc-20200307.

Excellent job, really :) Please can you tell me what was wrong when trying to generate NEWT native library?

Thanks !
There was a compilation issue because it didn't find some SWT classes. But as I didn't need SWT support, I didn't look further since the 3 DLLs I needed were already generated. I wouldn't worry too much about that.

This is very useful for us, thank you for making it available! But our application uses the class com/jogamp/opengl/util/gl2/GLUT which doesn't seem to exist in the new jars. Does anyone know if it is it tied to the SWT/Native-Window stuff that couldn't be built, or if there might be another way to make sure it is provided? Or has it been deprecated in 2.4? I'd like to learn what I can about my chances before attempting the MacOS-ARM build myself.

GLUT still exists:
https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/opengl/util/gl2/GLUT.html

Moreover, I've just checked in jogamp-fat.jar, GLUT is still there, there's nothing wrong.

Yes, GLUT still exists. I just removed from jogl-all.jar some classes not needed by Sweet Home 3D (by the way, I renamed this JAR file jogl-java3d.jar on my side to avoid misunderstandings).

I see, thanks! I found I can use the jars and libs provided with SweetHome if I put another jar that has GLUT in my classpath but that seems like an ugly way to handle this. (Sweet Home 3D is a dandy product, by the way. We're remodeling right now so I'm glad I ran into it!)

Is there a correct way to use an existing prebuilt jogamp-fat.jar (e.g. https://jogamp.org/deployment/jogamp-next/fat/jogamp-fat.jar ) with these new jnilib files or would it need to be rebuilt from scratch with references to the new architecture? (Just dropping the new libs into the same directory as the fat jar doesn't let it find them, of course, but I'm wondering if there are additional tweaks to the JRE invocation or edits to the fat jar that might do it.)

Emmanuel's changes should be put into a pull request or something similar, Sven should review his changes and produce a new build.

Next step, I tried to prepare a .app bundle for macOS to let users make tests without installing Java.
This required the jpackage command found in Azul Open JDK 15 that replaces the missing javapackager of Oracle Java. To get a "universal" .app bundle able to run under x86_64 and arm_64 architectures, I also merged the Contents/MacOS executable and Java runtime .dylib files contained in the .app bundle generated by jpackage with the lipo command (see my previous message).
Finally, I signed the application with entitlements described here and successfully submitted it for notarization to Apple.
The resulting application can be found in SweetHome3D-6.4.2b-macosx.dmg (81.6 MB).

Hi,

Nice work ! Could you share somewhere the whole jog/gluengen arm64 build ?

Thanks in advance

Stephane

You'll find the universal x86_64 and arm64 .dylib files for JogAmp Build v2.4.0-rc-20210111 in this folder. Other files are not changed.

Thanks !

Thanks for compiling and supporting the binaries which i tested in my 3D application --> https://github.com/Christoph-Lauer/Sonogram
 
The Java3D feature works only half the time now, but on Apple Silicon. Sometime it worked, sometimes not, without any error message. It simple hangs 50% chance.

I advise you to try to reproduce your bug without Java3D first in order to determine whether the problem comes from JOGL or from Java3D.

UPDATE --> The bug is only with the native RETINA display, not with an external 5K Display.  

A few users reported that Sweet Home 3D could hang too with JOGL v2.4.0-rc-20210111, but I didn't find where this deadlock could come from yet. It's probably bound to the modifications for macOS made last year (see this commit and this one). I was wondering if synchronizing on another existing lock (like the one returned by Component#getTreeLock) would help, but I didn't try yet (and my suggestion might be just stupid or nonsense).

The second commit you mentioned might be the culprit but it's difficult to know without testing on a real machine.

Hi,

Thanks to Manu for sharing hints on building. I have been able go a little further : keeping SWT in build and updating macOS-universal jars with the x86+arm dylib, which allows using the same jar for Intel or Arm processors.

I have been able to run a small demo program on two Macs, one displaying GL version, the other showing the Jzy3D surface tutorial, so I can say it works... BUT when running the JOGL JUnit tests suite, lot of them are crashing the JVM. They're still running so I'll investigate a bit later and tell you. Gluegen JUnit tests are OK.

I'll share the prebuilt jar as soon as possible. In the meantime, you may wish to read the recipe in this readme. I have mirrored the jogl and gluegen repo to be able to store my edits somewhere, so you may restart from the feature/macosx-arm64 branch. For now the ant build is modified to work on macOS+arm, but is not generalized to support both x86 and arm.

I'll be happy to participate in testing the hangs recently discussed.