JOGL for Mac ARM Silicon

Hi,

Maybe try the rc4 release I shared ?

I sent a link indicating how to get it from maven. If you don’t want it, you can download an rc4 as a zip file. Both provide patched Dylib files for ARM.
If this still does not work, you can find on my jogl GitHub clone a howto to quickly build the native binding .

I encounter the mach-o message you mention when I try loading an ARM dylib in a x86 jvm . Or vice versa . Did you check your PATH or DYLIB_LIBRARY_PATH do not refer to old libs ?

Hope this helps!

Hello,

Now that the hanging issue can be reproduced, it's much easier to try to find where it occurs in Sweet Home 3D and other JOGL programs.
First, note that this issue happens also when the free version of Rectangle application is running.

After a few tests, I found it happened when a Canvas3D instance is removed from the hierarchy of its container. With this in mind, I let the GC handle container hierarchy cleanup automatically but this delayed only the bug which eventually happened later. It looked like that a patch in Sweet Home 3D wouldn't be enough, but that some changes were required in JOGL itself.

Then after a few refinements in the part of jogamp.opengl.macosx.cgl.MacOSXCGLContext class which handles GL layer detachment and destruction, I found that calling OSXUtil.RunOnMainThread in NSOpenGLImpl#release without waiting its completion (first parameter set to false instead of true) would fix the issue. Eureka!

But when testing under older macOS 10.9 and 10.13, I experienced a similar hanging bug when setting the first parameter of OSXUtil.RunOnMainThread to false even when BetterSnapTool or Rectangle don't run! As the recent changes in the MacOSXCGLContext class were mainly programmed for macOS 10.15 (see the bug #1398), I propose for the moment to keep wait parameter to true only for macOS versions < 10.15 (note that I also tried to simply ignore OSXUtil.RunOnMainThread for old macOS versions, because the call to CGL.setContextView(ctx, 0) that it makes didn't exist before the fix of the bug #1398 but this didn't work).
This won't solve the hanging issue under older macOS versions, but at least, we can ask users to quit BetterSnapTool, Rectangle and the like under these macOS versions (or upgrade their system if they can), until we find a better solution.

Therefore, the current proposed change is to replace the statement:

OSXUtil.RunOnMainThread(true /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );

by (for your information, 10.16 version number is returned by Java 8):

boolean wait = System.getProperty("os.version").startsWith("10.") 
    && !System.getProperty("os.version").startsWith("10.15") 
    && !System.getProperty("os.version").startsWith("10.16");
OSXUtil.RunOnMainThread(wait /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );

You can test this solution with the modifications made to jogl-all.jar file available in the ZIP file jogl-all-2.4.0-rc-20221117.zip.
I tested it under macOS 10.9, 10.13.6, 12.6.1 Intel, 13.0 ARM and will test it under other macOS versions in the coming days (see further post).

Hope you followed me!

Hi all,

Success!
After installing XCode on my new iMac,  I could use the lipo command.
I used it to extract arm64-only dylibs from the universal dylibs I had gotten from
Sweethome3d and installed these dylibs in place of the universal ones.  
Using the arm64 Zulu JDK 8, everything just worked correctly the first time, no more
loader error messages.
It was immediately clear that it had found the arm64 versions of the libraries,
since the frame rates jumped by 25-50% over the speeds using an Intel JDK 8.
I have since tested this successfully with the arm64 versions of
Eclipse Temurin AdoptOpenJDK 11.0.7 and OpenJDK 11.0.17.

I wonder if there is some hidden flag somewhere that is causing the loading process
to choose to create an x86_64 library instead of an arm64 library from the universal dylib file,
leading to the loader error message in my previous post.

Thanks to manu and martin for their helpful responses.

Charlie

Thank you a lot for sharing your findings.

I referenced your solution in my JOGL clone issue list here.

Thank you Martin.

I ran more tests this morning, and I confirm that setting the first parameter of OSXUtil.RunOnMainThread to false worked also in Sweet Home 3D for macOS 10.15, macOS 13 Intel and even for macOS 10.14, which is very good news because it's the last macOS version which supported 32 bit applications that some people may be obliged to keep.
Therefore, this solution works for macOS versions from 10.14 to 13, but the test I proposed to add in NSOpenGLImpl#release must cite 10.14 too.
The proposed change is finally to replace the following statement in jogamp.opengl.macosx.cgl.MacOSXCGLContext class:

OSXUtil.RunOnMainThread(true /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );

by:

String osVersion = System.getProperty("os.version");
boolean wait = osVersion.startsWith("10.") 
    && !osVersion.startsWith("10.14") 
    && !osVersion.startsWith("10.15") 
    && !osVersion.startsWith("10.16");
OSXUtil.RunOnMainThread(wait /* wait */, true /* kickNSApp */, new Runnable() {
    @Override
    public void run() {
        CGL.setContextView(ctx, 0);
    } } );

This solution is programmed in the jogl-all.jar file available in the ZIP file jogl-all-2.4.0-rc-20221118.zip and also in SweetHome3D 7.0.2d where you can now import furniture without the hanging issue. I also changed the Implementation-Version value to 2.4.0-rc-20221118 in the MANIFEST.MF file of jogl-all.jar to avoid any confusion.

It would be nice to commit this change in JOGL code, but I don't have the keys for that...

Hey, I downloaded the latest Jars from the latest build which I assume supports Apple Silicon and x86. I still get this error when trying to run a simple 2d program,

Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000/file_cache/jln4668414692759400130/jln14154233556274098092/natives/macosx-universal/libgluegen_rt.dylib
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)
        at java.base/java.lang.Runtime.load0(Runtime.java:768)
        at java.base/java.lang.System.load(System.java:1837)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:604)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:64)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:107)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:488)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:427)
        at com.jogamp.common.os.Platform$1.run(Platform.java:321)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:290)
        at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:154)


Thanks in advance.

This looks similar to the problem discussed here.

The issue has been solved by changing permissions set by the DEB package manager.

Does this solve your problem?

Nope. Error still persists. I executed chmod 755 on /Library/Java/JavaVirtualMachines/zulu-8.jre/Contents/Home/lib/jspawnhelper and /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/lib/jspawnhelper and changed their permissions as needed.
I didn't change the permissions to other executables however; do I need to do that?

Thank you for your contribution Emmanuel.

Then enable debugging information in console by adding the VM argument -Djogamp.debug.IOUtil and then tell us what you get.

Manu wrote

It would be nice to commit this change in JOGL code, but I don't have the keys for that...

Maybe you can create a pull request here as some other did before. I can't promise to make a full rebuild of JOGL soon, but at least your changes remain available for all (in addition to your explanations).

Hi Martin,

I am also getting the same error with "v2.4.0-rc-20210111" on macOS aarch64. I am using the jogamp-fat.jar. When I add the debug VM argument, I get the following:

IOUtil.getTempRoot(): tempX1 </var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T>, used true
IOUtil.getTempRoot(): tempX3 </var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T>, used false
IOUtil.getTempRoot(): tempX4 </Users/kevin>, used true
IOUtil.getTempRoot(): tempX2 <null>, used false
IOUtil.testDirImpl(tempX1): </var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T>, create true, exec false: true
IOUtil.testDirImpl(tempX1): </var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T/jogamp_0000>, create true, exec false: true
IOUtil.getTempRoot(): temp dirs: exec: /var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T/jogamp_0000, noexec: /var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T/jogamp_0000
IOUtil.testDirImpl(testDir): </var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T/jogamp_0000/file_cache>, create true, exec false: true
Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/7g/50bnc9b90_z_gfy7v9g_tckr0000gn/T/jogamp_0000/file_cache/jln11059991141486245866/jln11144841344427274955/natives/macosx-universal/libgluegen_rt.dylib
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)



Am I using the wrong build? Please let me know if you need more information.

Hi,

You are not using the appropriate release. The one indicated earlier in this discussion will work on ARM.

I have been testing the build you forwarded me to for the past day and everything is working beautifully. Thank you very much for this build and for pointing me in the right direction.

Tou are welcome, Thanks for the feedback !

Martin wrote

Then enable debugging information in console by adding the VM argument -Djogamp.debug.IOUtil and then tell us what you get.

Hey, sorry I didn't see your reply.
That's what I get after adding the debugging VM argument:

IOUtil.getTempRoot(): tempX1 </var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T>, used true
IOUtil.getTempRoot(): tempX3 </var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T>, used false
IOUtil.getTempRoot(): tempX4 </Users/belalshareb>, used true
IOUtil.getTempRoot(): tempX2 <null>, used false
IOUtil.testDirImpl(tempX1): </var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T>, create true, exec false: true
IOUtil.testDirImpl(tempX1): </var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000>, create true, exec false: true
IOUtil.getTempRoot(): temp dirs: exec: /var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000, noexec: /var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000
IOUtil.testDirImpl(testDir): </var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000/file_cache>, create true, exec false: true
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/2v/3dmc82v53rv9lb3rgkhgpc940000gn/T/jogamp_0000/file_cache/jln5153096722597349623/jln11067003440662630275/natives/macosx-universal/libgluegen-rt.jnilib
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2408)
        at java.base/java.lang.Runtime.load0(Runtime.java:785)
        at java.base/java.lang.System.load(System.java:2011)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:603)
        at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63)
        at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:106)
        at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:487)
        at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:421)
        at com.jogamp.common.os.Platform$1.run(Platform.java:317)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
        at com.jogamp.common.os.Platform.<clinit>(Platform.java:287)
        at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:147)
        at SwingUI.main(SwingUI.java:24)

Process finished with exit code 1

Nothing wrong there.

So maybe some of the native are not extracted from your Jars.

Enabling -Djogamp.debug.JarUtil -Djogamp.debug.JNILibLoader will display the jar extraction and native libs loading
- The first to be mentionned in console should be Gluegen.
- Find something looking like : JarUtil: EXTRACT[1]: [gluegen_rt -> ] natives/macosx-universal/libgluegen_rt.dylib -> /var/folders/d2/85g_sxm91rg71yyky4gg6l6h0000gn/T/jogamp_0000/file_cache/jln7779685231866426360/jln1167618764182536803/natives/macosx-universal/libgluegen_rt.dylib: 85840 bytes, addedAsNativeLib: true
- Search if the folder containing libgluegen_rt.dylib if it also contains other dylibs. There should be 6 including gluegen.

If not search for reasons in console and tell us!

After facing the same bug as yours, I understood that in some situation - depending on your code, the GLProfile class gets never called which prevent the JOGL jar from being expanded.

SO THE FIX IS

GLProfile.initSingleton();

at the beginning of your program will force the jars to be expanded and then you do not miss any lib.

If you're right, maybe disable the automated native library loading and set the library path. Relying on a broken mechanism isn't pleasant :(

Thanks .
How should we do this ?