Exception with old version of jogl library on ARM Mac

[AlexanderPolyakov]

trafficstars

Issue

Locally built client on ARM Mac produces an Exception:

     [java] Exception in thread "Haven main thread" java.lang.UnsatisfiedLinkError: /private/var/folders/sj/cqrbzbjs1t18v3jgtsd3vtm00000gn/T/jogamp_0000/file_cache/jln16038627640270459009/jln6062449462191120969/natives/macosx-universal/libgluegen_rt.dylib: dlopen(/private/var/folders/sj/cqrbzbjs1t18v3jgtsd3vtm00000gn/T/jogamp_0000/file_cache/jln16038627640270459009/jln6062449462191120969/natives/macosx-universal/libgluegen_rt.dylib, 0x0001): tried: '/private/var/folders/sj/cqrbzbjs1t18v3jgtsd3vtm00000gn/T/jogamp_0000/file_cache/jln16038627640270459009/jln6062449462191120969/natives/macosx-universal/libgluegen_rt.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/private/var/folders/sj/cqrbzbjs1t18v3jgtsd3vtm00000gn/T/jogamp_0000/file_cache/jln16038627640270459009/jln6062449462191120969/natives/macosx-universal/libgluegen_rt.dylib' (no such file), '/private/var/folders/sj/cqrbzbjs1t18v3jgtsd3vtm00000gn/T/jogamp_0000/file_cache/jln16038627640270459009/jln6062449462191120969/natives/macosx-universal/libgluegen_rt.dylib

Repro steps

• Build client with ant bin command
• Run client with ant run command

System specs

java --version:

java 17.0.9 2023-10-17 LTS
Java(TM) SE Runtime Environment (build 17.0.9+11-LTS-201)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.9+11-LTS-201, mixed mode, sharing)

javac --version:

javac 17.0.9

ant -version:

Apache Ant(TM) version 1.10.14 compiled on August 16 2023

Proposed solution

Latest release of jogamp library fixes this issue, so it can be beneficial to update jogamp library fetched from the website to the new version. When .jar files are replaced in lib/ext/jogl directory with the new release (https://jogamp.org/deployment/v2.5.0/archive/) this error goes away.

[dolda2000]

Latest release of jogamp library fixes this issue

It does indeed, however it also drops support for 32-bit Windows, which is used by far more people than MacOS, so it is not used by default by the client.

It can be used manually, however. The official client has a separate launcher for it available at https://www.havenandhearth.com/java/hafen-jogl-2.5.0-launcher.jar. For building it from source, you can remove the lib/ext/jogl directory (or run ant clean), and then change the JOGL URL in the build.xml file to say 2.5.0 instead of current. Building the client will then download JOGL 2.5.0, and since a downloaded copy of JOGL won't be redownloaded unless removed again, you can safely revert build.xml again.

The JOGL guys have said that they will bring 32-bit Windows support back with 2.6.0, so at that point I expect to be able to upgrade the JOGL version used by default.

[dolda2000]

You might also want to try whether the LWJGL renderer works for you on MacOS. To do so, set the haven.renderer sysprop to lwjgl when launching the client (ie. add -Dhaven.renderer=lwjgl as a JVM argument). If it works, that would be when using the LWJGL version that is downloaded by default.

[AlexanderPolyakov]

I see. I didn't know that 2.5.0 dropped Win32 support and that there're still some Win32 users out there! So high hopes for 2.6.0 to provide a common ground for different OSes.

I'll try LWJGL to see if that works, but building with a local copy of 2.5.0 works too, I was mostly concerned about other users encountering same problems, like this or this. They're not numerous, but still.

[dolda2000]

I was mostly concerned about other users encountering same problems

Yes, I agree, and it would be very nice to fix it, but for now I think it is what it is, unfortunately. I'm hoping it won't be too long until 2.6.0 is released, but JOGL's release pace has been up lately, so I think there's a good chance.

there're still some Win32 users out there

Just FYI, it's not so much that people use 32-bit Windows, as it is that they're using a 32-bit JVM on 64-bit Windows. Apparently, java.com still distributes 32-bit JVMs by default for whatever reason.