Non-Support of MacOS Arm processors in client's gluegen_rt

Forum for alternative clients, mods & discussions on the same.

Non-Support of MacOS Arm processors in client's gluegen_rt

Postby xyzzy57 » Sat Nov 27, 2021 9:40 pm

I have an ARM (not x86) based Mac running MacOS Monterey 12.0.1

Haven runs successfully using Oracle Java's JRE (Java 8 Update 311)

It does not run when I use Oracle's JDK 17 for Arm 64.

In particular, it crashes, complaining about gluegen_rt not containing an arm version in its macos universal binary

gluegen_rt.jar does have arm versions for various other operating systems.

I imagine this may be a simple matter of build time options when generating the client, and if it were fixed, those of us on ARM-based Macs would get better performance/less lag when running the client. (I presume the JRE is emulating the x86 architecture to run haven at all.)

I'd appreciate if the developers would look into this. I might be able to figure this out myself, but at this point I don't even count as "new to java development" - more like "thinking about learning java, and playing with the haven client as a learning exercise". And more importantly, if they make this change, everyone gets it, and continues to get it on every update.

Finally, my apologies if I'm totally misunderstanding what I see happening here.

And for completeness, here are the messages I see.

Code: Select all
java.lang.UnsatisfiedLinkError: /private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib: dlopen(/private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib, 0x0001): tried: '/private/var/folders/zk/926c34c13hg6y_y5gyvp7hy40000gn/T/jogamp_0000/file_cache/jln15681904295245521471/jln2148212923575489460/natives/macosx-universal/libgluegen_rt.dylib' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e')), '/usr/lib/libgluegen_rt.dylib' (no such file)
   at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
   at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:384)
   at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:228)
   at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:170)
   at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
   at java.base/java.lang.Runtime.load0(Runtime.java:755)
   at java.base/java.lang.System.load(System.java:1953)
   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(AccessController.java:318)
   at com.jogamp.common.os.Platform.<clinit>(Platform.java:290)
   at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:154)
   at haven.JOGLPanel.mkcaps(JOGLPanel.java:73)
   at haven.JOGLPanel.<init>(JOGLPanel.java:93)
   at haven.MainFrame.<init>(MainFrame.java:172)
   at haven.MainFrame.main2(MainFrame.java:445)
   at haven.MainFrame.lambda$main$0(MainFrame.java:481)
   at java.base/java.lang.Thread.run(Thread.java:833)
xyzzy57
 
Posts: 109
Joined: Thu Aug 19, 2021 9:41 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby xyzzy57 » Sat Nov 27, 2021 11:10 pm

There's probably no point in fixing this, at least for those using Oracle's java.

AFAICT, the JRE for MacOS only comes in an intel flavor, and the only way to get an ARM flavour is to install the ARM SDK.

The set of people likely to do that would presumably include only tinkerers who own M1 Macs. (Among H&H players, that might be a set containing exactly one person ;-()

If Haven is typical, they'll soon find that the result is that most java apps they download won't work, having only intel support.

I've now uninstalled java to the best of my ability (Oracle's documentation is incomplete or incorrect), and reinstalled intel versions on my arm mac. (I had to install the intel JDK as well as the JRE to get my system unbroken.) The whole thing is running emulated, as it must have been while I still only had the JRE installed.

IMNSHO, Oracle has dropped the ball here, possibly with a little help from Apple.

Other Java implementations, like OpenJDK, seem to be in much the same state, judging only from their web sites.

There's probably no point in having the Haven client try to get ahead of the curve.
xyzzy57
 
Posts: 109
Joined: Thu Aug 19, 2021 9:41 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby pawnchito » Sun Nov 28, 2021 12:39 am

You said so many words and I wish I understood any of it. My wife plays on a Mac and has been using Ender client with great success but she uses the OS Big Sur.
User avatar
pawnchito
 
Posts: 1086
Joined: Sat Apr 07, 2018 11:52 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby xyzzy57 » Sun Nov 28, 2021 3:14 am

A little knowledge is clearly a dangerous thing. Here's the current state of my still incomplete understanding:

It appears that gluegen is a third party library from https://jogamp.org, used by all the haven clients.

It either doesn't support Mac M1 chips currently, or the haven clients aren't picking up the M1 supporting version, or not building it with that support. A very fast scan of the GlueGen build instructions suggests that it probably does support ARM for both Mac and iOS. But I haven't tried it.

Oracle's java JRE is itself pure intel on the mac, so anyone using it is running java by emulating intel chips with Apple's Rosetta.

Oracle's JDK comes in two flavours on the mac - intel and ARM.

The arm version doesn't know how to emulate intel for things that aren't available as native arm code - this may not even be possible. So none of the haven clients can run on an ARM (aka M1) mac using the ARM JDK.

I don't know about ARM/M1 support from other JVM suppliers. If they are still in the same place as Oracle of barely supporting native ARM code on the Mac, then this will be a very rarely encountered problem.
xyzzy57
 
Posts: 109
Joined: Thu Aug 19, 2021 9:41 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby pawnchito » Sun Nov 28, 2021 8:39 pm

Alright so bear with me because my brain is smoother than a babies bottom. Wife is being asked to upgrade to Monterrey OS from Big Sur, it sounds like the issue is not with the OS specifically but with the chipset? She has an intel chipset so this particular issue should not follow correct? Going to push off the upgrade a bit if possible.
User avatar
pawnchito
 
Posts: 1086
Joined: Sat Apr 07, 2018 11:52 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby MagicManICT » Sun Dec 05, 2021 3:27 pm

I thought I had seen an issue with JOGL and the M1 processor previously. I'm not sure if this thread will be helpful, but I dug it up. viewtopic.php?f=47&t=69809

The only other thing I can think of at the time is to ask if you have tried earlier versions of Java, or if this is strictly a v17 issue.
Opinions expressed in this statement are the authors alone and in no way reflect on the game development values of the actual developers.
User avatar
MagicManICT
 
Posts: 18437
Joined: Tue Aug 17, 2010 1:47 am

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby loftar » Sun Dec 05, 2021 9:54 pm

I didn't even think there was a JRE for ARM on Mac OS yet. I thought all ARM Mac Java ran through Rosetta, so I hadn't even bothered to look in to it.

The problem, though, is that JOGL's build process doesn't support cross-compilation, so I can't build a MacOS ARM version without having an ARM Mac. Since JOGL supports both MacOS and ARM, unless there is some interaction between the two that they would need to take special heed of, you may be able to build one yourself, in which case you could probably use it directly as is, and if you send it to me I could potentially include it in the standard distribution (unless there are any complications that I'm not aware of). Otherwise, we'll simply have to wait for the Jogamp guys to build it for us.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby Limitless0 » Fri Jan 07, 2022 12:48 am

loftar wrote: Jogamp guys to build it for us.


I highly doubt that's going to happen as the last stable JOGL build was released in 2015
Limitless0
 
Posts: 11
Joined: Wed Jan 05, 2022 4:40 pm

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby loftar » Mon Jan 31, 2022 12:34 am

Limitless0 wrote:I highly doubt that's going to happen as the last stable JOGL build was released in 2015

Yeah, I have actually started wondering lately whether I should switch over to LWJGL. Now that the rendering system isolates the rest of the client from the OpenGL backend, that is a realistic option. My main argument against it, really, is that LWJGL is far more crash-prone than JOGL is (in case of wrong or marginal inputs), and I'm not sure that a risk of more JVM crashes really is what the client needs right now.
"Object-oriented design is the roman numerals of computing." -- Rob Pike
User avatar
loftar
 
Posts: 8926
Joined: Fri Apr 03, 2009 7:05 am

Re: Non-Support of MacOS Arm processors in client's gluegen_

Postby APXEOLOG » Wed Feb 02, 2022 12:25 pm

loftar wrote:Yeah, I have actually started wondering lately whether I should switch over to LWJGL. Now that the rendering system isolates the rest of the client from the OpenGL backend, that is a realistic option. My main argument against it, really, is that LWJGL is far more crash-prone than JOGL is (in case of wrong or marginal inputs), and I'm not sure that a risk of more JVM crashes really is what the client needs right now.

I think there is no way to not migrate if you plan to develop the game. Rendering through the dead libraries with discontinued support means you will not be able to leverage modern rendering standards and GPUs. It would be even better if you would target Vulkan instead of OpenGL, but I doubt you will have enough resources to do that. Regarding LWJGL - I don't have any info about its stability, but I think it would be nice to try it
W10 Meme Plot | W9 Mantis Garden | W8 Core | W7 Ofir | W6 the City of Dis | W5 Vitterstad | W4 A.D. | W3 Mirniy
jorb wrote:All your characters will be deleted, and I will level every village any one of them were ever members of.
User avatar
APXEOLOG
 
Posts: 1267
Joined: Fri Apr 23, 2010 7:58 am
Location: Somewhere on Earth

Next

Return to The Wizards' Tower

Who is online

Users browsing this forum: No registered users and 7 guests

cron