Library names per desktop enviroment

zxuiji · September 4, 2022, 10:29am

I’d like glfw to switch from fixed libglfw.so on linux to libglfw-x11.so etc and make libglfw.so just a wrapper library that searches for them, hooks them, then calls whatever internal initialiser it deems suitable such as libGlfwSubInit(), by doing so can resolve the common issue of “wrong library” by just trying each of those in turn until one succeeds or you run out of libraries to search for and try, take this example of output from my own wrapper I’m developing:

...
Attempting to bind library 'libpawwfx-glfw.so'...
Searching for 'libglfw-x11.so'...
Not found, attempting to open instead...
Searching for 'libglfw-wayland.so'...
Not found, attempting to open instead...
Searching for 'libglfw.so'...
Not found, attempting to open instead...
Hook acquired, attempting to initialise...
Success!
Generating library path with libpawvfx-glew.so...
Attempting to bind library 'libpawvfx-glew.so'...
Searching for 'libGLEW.so'...
Not found, attempting to open instead...
Hook acquired, attempting to initialise...
Success!
Launching Graphics Tests...
...

If making glfw a wrapper to them is not possible then make it a symlink to libglfw-x11.so etc, that way the distros can allow multiple desktop environments more easily while also maintaining backwards compatibility for old software that doesn’t support searching for the right library for the DE they’re in.

dougbinks · September 5, 2022, 11:07am

My understanding is that GLFW has moved to runtime selection of the platform via the GLFW_PLATFORM init hint :

github.com/glfw/glfw

Runtime selection of platform (or window system)

glfw:master ← glfw:runtime-multi-platform

opened 07:59PM - 30 Aug 21 UTC

elmindreda

+3720 -2607

This is an initial but mostly functional implementation of compiling GLFW for mu…ltiple platforms. It should be far enough along to both test further and gather feedback on its design, implementation and documentation. By default the platform is detected and selected automatically by `glfwInit` but it can also be selected explicitly via the `GLFW_PLATFORM` initialization hint. Most platform functions (but not all) are now called from shared code via the function pointer struct `_GLFWplatform` provided by the selected platform. The timer, thread and module loading platform functions are still called directly by name and the implementation chosen at link-time. These functions are the same for any backend on a given OS, including the Null backend. The Null backend is now always included but needs to be explicitly selected via init hint. The other backends are now enabled via CMake dependent options following the `GLFW_BUILD_<platform>` pattern instead of a mix of automagic and ad-hoc option names. Note that there is still work to do, including at least: - [ ] ~The detection logic for X11 and Wayland is still placeholder.~ - [x] There is no guide documentation. - [x] The new functions have not been reviewed for thread safety. - [x] The changelog entries are incomplete. - [ ] ~By default non-macOS Unix builds will currently not include Wayland support.~ - [ ] ~The joystick implementation selection on non-macOS Unices is kludgy.~

So there won’t be separate libraries for X11 and Wayland anymore once this has been released.

zxuiji · September 25, 2022, 1:00pm

Forgot about this post, thanks for letting me know, I’ll target that in future when it’s released, I’ll let devs of the desktop environments just compile their own version instead, they can just install/uninstall libpawwfx-glfw-x11.so etc with paw --install-lib <source_path> & paw --remove-lib for libpawwfx.so to search for prior to the generic one, that should resolve the issue