[macOS] GLFW error 65548: Cocoa: Regular windows do not have icons on macOS

[ivxvm]

Version

3.3.0 (nightly)

Platform

macOS arm64

JDK

Zulu OpenJDK 11.0.13

Module

GLFW

Bug description

I compiled and bundled together nightly jars into one fat jar and used that with Minecraft 1.16.5. The game wouldn't launch with error GLFW error 65548: Cocoa: Regular windows do not have icons on macOS. So I went to code and commented out everything inside glfwSetWindowIcon, nglfwSetWindowIcon, made glfwSetWindowIconifyCallback return null, and nglfwSetWindowIconifyCallback return 0. After this, game launches successfully and works great.

Decision should be made whether this is a bug that should be fixed in lwjgl3 or it's responsibility of library users to not even call said procedures when running under macos. But it would clearly make many apps automatically compatible without touching their code, if those procedures were just made NOPs in macos library builds.

Stacktrace or crash log output

GLFW error 65548: Cocoa: Regular windows do not have icons on macOS

[Spasi]

This change in behavior was introduced with glfw/glfw@9a87c2a. When Minecraft is updated to use LWJGL 3.3.0, they'll have to either ignore the GLFW_FEATURE_UNAVAILABLE error or stop calling icon functions on macOS.

LWJGL provides lightweight bindings and the policy is to not mess with the implementation of the native libraries, except in rare cases (e.g. when a serious bug fix takes too long to be merged upstream). This is not such a case.

[Pyrotex7]

If I may ask, what exactly is the issue stopping GLFW from being able to use that feature on macOS? And would a fix be able to be implemented from something like a launcher and not only by messing with the actual LWJGL or Minecraft code?

[Spasi]

If I may ask, what exactly is the issue stopping GLFW from being able to use that feature on macOS?

Windows do not have icons on macOS, applications do. Icons go into bundles and afaik there's no API to define them programmatically.

And would a fix be able to be implemented from something like a launcher and not only by messing with the actual LWJGL or Minecraft code?

I don't think so.

[Pyrotex7]

I have some more expansive questions regarding this issue, but I don't want to continue them here, where might I ask those?

[SWinxy]

I have some more expansive questions regarding this issue, but I don't want to continue them here, where might I ask those?

Go ahead. What's your question?

[Pyrotex7]

All I’m trying to do is run Minecraft on the Apple Silicon macs that use ARM based processors.

• The issue is, I can’t use the LWJGL 3.3 distribution with the latest version of GLFW, because it does not support versions that used LWJGL 3.2, 1.17 and below, as it throws an error not thrown before when using the latest version of macOS (in this sense, the newer GLFW is doing it’s job, just the lack of it doing it’s job in earlier versions by not throwing an error made it able to run Minecraft on newer macOS versions).
• But I also can’t use LWJGL 3.2, because it’s not available for macOS arm64 (Apple Silicon).

Lunar Client is native for Apple Silicon, runs on the latest version of macOS, and runs versions as old as 1.8, so they’ve bypassed this issue somehow but I don’t know how.

I’m guessing the solution would be fixing older Minecraft versions to use LWJGL 3, or compile (and modify) older versions of LWJGL for Apple Silicon, both of which I don’t know how to do.

I’m open to suggestions, solutions, or just information on how to execute the two proposed solutions.

Also I can repost this on the forum if it’s too much for here.

[SWinxy]

I believe a Java Agent can work to intercept calls to GLFW, and silently handle the errors with the agent. I don't know how Lunar does it, though.

[Pyrotex7]

I’ll look into that, thank you!

[Samauroh]

MacOS Cocoa Hot Fix

Personal Fork Solution

Specify GLFW Library use via a location path using Prism Launcher