Apple Silicon Mac GLFW error on startup #7558
Comments
panther03
added
the
Triage
|
This is an issue with GLFW and Apple Silicon's Rosetta technology. I've said it, but it's not going through. |
TheCurle
added
1.15
1.16
Blocked Upstream
|
To clarify, this is indeed something that appears to be a issue on Apple's end. It may appear to be Forge's issue because we do more work before loading Minecraft, thus causing it to delay touching the GL context. Which could mean that whatever background task you were talking about is more likely to complete first and trigger the issue. But that doesn't mean it's caused by Forge. However, IF you can find someone who can reproduce {Because all our mac users/devs can't} then we could try to remediate it on our end. But Macs are notorious for doing graphics wrong, and not many people in the community have them. So developing for them is damn near impossible. |
|
I will just add speculation here that it could be an incompatibility with new mac silicon and LWJGL as well.. based on this: LWJGL/lwjgl3#601 there doesn't even seem to be native ARM64 libs for M1 yet, so this is probably an X86 emulation thing that's going wrong... |
|
Thanks for the response guys. I should probably clarify a couple things:
This is not true. This is completely independent of Rosetta; as I wrote in my original post, it is possible to compile/obtain all dependencies for Minecraft to run natively on M1 (even MultiMC.) You can see in the logs that this is the case, since I'm using an aarch64 JVM and the JNI requires a consistent architecture for native libraries. Note however that the issue still occurs on Rosetta, which is why I'm writing this as a generic "apple silicon" issue (it does not occur on x86_64 macs running the same big sur). That being said, it is true that LWJGL themselves do not yet ship native libraries, and that they are probably not tested nearly as thoroughly due to a lack of CI and other testing facilities. So maybe that's what it is.
Fair enough. It should be easy to re-create on any M1 system though, as far as I know. |
|
Reproduced: |
|
Yes, there are no M1 LWJGL natives, so Rosetta is interpreting them for x86_64 regardless of how you start the game. Still not something we, or anyone but Apple, can fix. |
That's simply not true. Have you not read my post? Do you need me to provide the libraries themselves so you can run |
|
Great. It's compiled. they've supported arm for a while. But it's not compatible, and i don't see any fixes in their repository to work around the missing APIs on the newer Mac system. |
|
It seems to be a bug in upstream macOS. I've removed the failing call in glfw and forge works fine. I've built a version of glfw with the failing function just returning null (sdirkwinkel/glfw@310d5c3) you cat get the lib here: I'm able to run forge modpacks with this. FPS are quite good. |
|
Yes, they deprecated the APIs that GLFW/LWJGL use. Hence my insistence from the start that this is an Apple thing. We can only wait until a fix is issued upstream. |
|
This is not about rosetta. I'm using native java/glfw on aarch64. It seems to be just a change to display handling code. The same issue appears with airplay displays. I do agree that forge can't fix this. It should be fixed in glfw/macOS |
I tried your libglfw.dylib file, could not get it to work (get the same error as described above). I just tried replacing the old file with yours, anything else I must do? Do I need to replace all files in lwjglnatives folder or only the libglfw.dylib one? |
|
You should just need the libglfw.dylib. How are you running Minecraft? Can you provide a log? The fix seems to work for at leas some people: yusefnapora/m1-multimc-hack#1 |
|
@0xQSL Thank you for your great patch! It works in 60fps+ on my M1 Macbook. How to guide in Japanese: https://qiita.com/kawanet/items/57a35446b7daa903dfe9 |
|
Looking at the patch that 0xQSL linked, it appears that the only significant difference in behavior between Apple's glfw library and the hacked one is that Apple's calls _glfwInputError(GLFW_PLATFORM_ERROR, "Cocoa: Failed to find service port for display"); before returning a null pointer, while the hacked version simply returns the null pointer. |
|
This is not going to become a place to hack around in your natives. |
|
Minecraft itself checks for glfw errors when it initializes the main window, and crashes if it detects an error. If just ignoring the error and continuing makes it work, it should be possible to detect this particular error and not throw an exception (in |
|
@LexManos: in ClientVisualization.java - I don't know that this is the issue, because I'm only poking around in Forge's source code, but it's a possibility. |
|
fyi, this is not a bug in macOS, but rather a deprecation of an entire API layer that no longer works on Apple Silicon. A correct patch has been merged to glfw master. The patch supplied above (early null return) shouldn't have any bad side effects though, and is fine as a stop gap imho. |
|
@nevyn Do you know when the 3.3.3 release is scheduled for glfw? |
@saintentropy Sorry, I don't. I'm not a maintainer on that project, I just wrote the above linked patch and wanted to correct some misinformation. Feels like an important fix to ship though, since it breaks glfw on all new macs. |
|
A fix for the |
|
This has been such a helpful thread, thank you so much! |
|
Once LWJGL is updated, we need to wait for Mojang to take it up and update the game to work with it. Updating the game ourselves can possibly be a monumental task, and would probably introduce a lot of unintentional bugs. Yet again, this is totally beyond our control. |
|
If you use MultiMC you can set the client to use the upcoming version of LWJGL, which from what I understand should fix the issue without Forge or Mojang having to ship. Kind of annoying having to tweak the instance so much but it'll work for the time being |
Can someone explain to me how to install this fix? |
|
We're not going to endorse installing binaries built by random people on the internet. |
|
Someone on Reddit had success using crossover. I’ll post the steps below “1. Install crossover This is my first MacBook/Mac in general so I’m still learning how the OS works. If you’d like a more confirmed way of doing it I’ll have to try and install it again to another bottle“ |
|
LWJGL has been updated to 3.3.0 snapshot 7 per LWJGL/lwjgl3#601 (comment), and the issue closed. Is that change sufficient to resolve the issues identified here? As I understand from above, this new library would need to be included by Mojang, not simply Forge. |
|
Can confirm this works without Crossover. I know this isn't relevant to Forge's issue, but I'm sure many others will arrive here like myself looking for a fix they can implement today
|
|
Look guys, this is resolved. It was a upstream issue. Update yourself, or wait for 1.17 where Mojang updates. |
Minecraft Version: 1.16.4
Forge Version: all versions from 35.1.4 to 35.1.13, as well as 35.0.0
Logs: https://paste.ee/p/lIYZ6
Steps to Reproduce:
Description of issue:
Upon launch of any 1.16.4 version with Forge installed, using native or Intel LWJGL, a GLFW error causes the game to crash:
Some say they have fixed this error using the argument
-Dfml.earlyprogresswindow=false, but for me and several others, adding the argument just causes the GLFW error to display in a popup window, and the error in the log is mostly the same:This does not happen in Vanilla, and I have also observed it in many forge 1.15.2 versions. I have also observed that the instance will very rarely launch successfully. I have no good explanation for this, and it's extremely inconsistent, but for some reason, sometimes it just decides it will launch fine, and in these cases the game will be perfectly playable.
In the instances I have been able to launch it, it has generally been on a new launch of MultiMC, which makes me wonder if this has something to do with GLFW initializing before forge; if it runs as a separate background process, it becomes a race to see which one inits first, and if you keep trying to launch the same instance, the code for GLFW is cached or something. Just a complete guess, I don't know how Forge uses GLFW internally.
The text was updated successfully, but these errors were encountered: