Support for _GLFW_X11 on MacOS with XQuartz about glfw

[elmindreda]

I've done this locally a few times but there's always been something that made it not worthwhile. Most recently, GLX context creation failed with an internal, CGL-related error on MacPorts XQuartz.

It would be a fun thing to add if time permitted getting it working properly, but that likely won't happen for a while. It's a very niche feature.

There's no need to create a separate PR for it.

[cblc]

Just one clarification: I don't build for XQuartz and Cocoa in the same executable, and, honestly, I doubt it would be a good idea to choose between XQuartz and Cocoa at runtime, because for example the OpenGL library is different (the Cocoa OpenGL framework vs the libGL.dylib of XQuartz). I just build two different executables to avoid undesired side effects.

[archbirdplus]

Only just noticed this issue after making my own PR.

for example the OpenGL library is different (the Cocoa OpenGL framework vs the libGL.dylib of XQuartz)

It looks like XQuartz libGL.dylib just wraps around AppleMetalOpenGLRenderer, according to lsof. I don't think it's very useful.

What is useful is that you can use other OpenGL drivers, such as Mesa LLVMpipe, which don't support Cocoa. That's what we're doing with Cubyz to get some Mac support. It's not hardware accelerated, but allows me to test all the features of the game.

GLX context creation failed

In my case the problem was glad.c not using glXGetProcAddressARB. I only had to change a couple of lines, but I don't know your setup.

[archbirdplus]

As for DYLD_FALLBACK_LIBRARY_PATH, I think that since neither XQuartz nor Mesa are installed by default, it should be left to the developers downstream to figure out how to package it. In case you didn't know, you can use -L or -R to build the path into your executable.