Last night I was made aware of the situation and posted about it on Twitter but for those who don't follow along, here's what happened.ġ4 hours ago, according to GitHub, the creator removed the Code of Conduct with a commit message titled "reclaim polymc from the leftoids". Unfortunately, it seems a developer on the Minecraft launcher PolyMC went completely rogue and so for your own safety, you should remove PolyMC from all systems. or helping github Vatuu/discord-rpc move to a modern JNA beyond 4.x (M1 support wasn't added until 5.7.Update: here's a fresh Steam Deck guide with Prism Launcher. splitting out the Discord dependency code to a separate optional module that Mac users could choose not to load The fix in this situation would be either: Since none of those match the architecture that java is running natively in on an M1 or M2 Mac (arm64), no platform specific code loads and you get class failures like this. But because this JNA is so old, all of the platform-specific library code is has is compiled for the wrong architectures:Ĭom/sun/jna/darwin/libjnidispatch.jnilib: Mach-O universal binary with 2 architectures: Ĭom/sun/jna/darwin/libjnidispatch.jnilib (for architecture i386): Mach-O dynamically linked shared library i386Ĭom/sun/jna/darwin/libjnidispatch.jnilib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 The jna-4.4.0.jar that's being downloaded contains com/sun/jna/darwin/libjnidispatch.jnilib for this on macOS. The issue is because the discord-rpc dependency relies on a JNA version and the version that's loading is 4.4.0 - which normally wouldn't be a problem, but in this case the code path it's going down in ends up relying on platform-specific native code, which means leaving the JVM and calling out to library/platform specific code. On an M1 Mac (unclear if this occurs on x86 Macs, though this has been reproduced on more than one M1 machine), trying both PolyMC with sdirkwinkel/m1-multimc-hack and ManyMC, Pixelmon crashes on launch: Again, that's a lot of background that isn't Pixelmon's fault, but it pertains to setup required to use Pixelmon. I don't know of anyone using the official launcher to do get this working. Alternatively, this method for using a different LWJGL is also provided. PolyMC or MultiMC with use a patched LWJGL 3.2.2 as described in this tutorial (this is a tutorial for using Aarch64 LWJGL, but the repo includes a patched GLFW.I don't see anyone recommending this and I didn't have luck with it, (but I was using a x86 JDK) but theoretically it makes sense. PolyMC or MultiMC with LWJGL 3.3.1 selected in the Versions tab of an instance.ManyMC, which automatically uses LWJGL 3.3.1.This is all to say that, on an M1 Mac, a functional Forge setup for 1.16.5 will either be using: This is probably workable with x86 code, but native code is nice. In combination with this, existing solutions use an Aarch64 JDK, along with Aarch64 LWJGL binaries. Use a patched LWJGL 3.2.2 which stubs out the affected code.Therefore, in order to use Forge on M1 Macs in a situation where LWJGL 3.2.2 would be used, we need to either: This was fixed with this GLFW pull request, which is shipped with LWJGL 3.3.1. This only causes a crash for Forge, though it's not a Forge bug but rather affected by the way Forge functions. As documented in this GLFW issue, M1 Macs deprecate a library required for GLFW initialization.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |