Support for _GLFW_X11 on MacOS with XQuartz

[cblc]

I just found that the dynamic loading of platforms at runtime is not ready for supporting XQuartz on MacOS (I guess that older versions of GLFW which linked directly to the X11 libraries worked fine, because I've found a couple of messages about GLFW and XQuartz).

I have done a commit in my fork which lets me build the X11 fine with XQuartz, and it works: cblc@0ab4fbb

The only problem is that you need to run the app executables prepending DYLD_FALLBACK_LIBRARY_PATH="/opt/X11/lib" to the executable, because otherwise dlopen() fails. I don't know if it's possible to make it easier and avoid defining that environment variable.

Before you ask, yes, I use the Cocoa backend on MacOS, but I like the idea of being able to switch to the X11 backend for testing purposes.

I'm not sure if the CMake files need any change, because I build GLFW with a custom Makefile.

If there's interest, I can make a PR, but I'm very new at GitHub and I'm not sure if that's possible because I committed #2419 in my fork before doing these changes, so I'm not really sure if I can do a "clean PR" which doesn't embed #2419

[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.

[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.

[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.