libGL.so.1 called libGL.so.3 on NetBSD

[prlw1]

Unfortunately on NetBSD, MesaLib is installed as /usr/X11R7/lib/libGL.so.3, so to get dear imgui to find it, I need

diff --git a/backends/imgui_impl_opengl3_loader.h b/backends/imgui_impl_opengl3_loader.h
index a077751c9..099360b87 100644
--- a/backends/imgui_impl_opengl3_loader.h
+++ b/backends/imgui_impl_opengl3_loader.h
@@ -666,7 +666,7 @@ static GL3WglProc (*glx_get_proc_address)(const GLubyte *);
 
 static int open_libgl(void)
 {
-    libgl = dlopen("libGL.so.1", RTLD_LAZY | RTLD_LOCAL);
+    libgl = dlopen("libGL.so", RTLD_LAZY | RTLD_LOCAL);
     if (!libgl)
         return GL3W_ERROR_LIBRARY_OPEN;
     *(void **)(&glx_get_proc_address) = dlsym(libgl, "glXGetProcAddressARB");

I suppose if you really care about the major number, you could #ifdef __NetBSD__, but it doesn't seem worth the complication, as chances are dear imgui will work with everyone elses libGL.so.2 should it ever come out.

[ocornut]

Out of experience, I wouldn't underestimate the subtle problems caused by those things.
This is best discussed at the original repo where the code is from: https://github.com/skaslev/gl3w

However I noticed GL3W received an update:
skaslev/gl3w@ec62d76
Which we didn't carry in https://github.com/dearimgui/gl3w_stripped
So it'd first need updating. But that change kept the "libGL.so.1" constant.

[ocornut]

Pinging @rokups in case they would be interested in updating our copy to align to latest gl3w and possibly be more X11/Wayland friendly with EGL support.

[PathogenDavid]

However I noticed GL3W received an update:
skaslev/gl3w@ec62d76

Worth noting this change actually happened as a result of #4810 (which is presumably still open as a reminder to merge those changes.)

[ocornut]

Thanks. I don’t have much access nor knowledge to linux and other unix based system so this would need a volunteer to catch up with it. As for OP’s specific issue it probably should be brought to main gl3w repo first.

[rokups]

Pinging @rokups in case they would be interested in updating our copy to align to latest gl3w and possibly be more X11/Wayland friendly with EGL support.

I do not really have any capacity left for anything lately.. Sorry

[prlw1]

I think you are all reading far more into what I wrote than there is. It really is as simple as, due to a historic accendent, the MesaLib that lives on other unix systems as libGL.so.1 is called libGL.so.3 when installed from base xsrc on NetBSD. There is no more to it than that. As my guess is that, as with libc the major number of MesaLib is very unlikely to change, my original patch should be fine. But as you seem to worried, this really should do the trick:

diff --git a/backends/imgui_impl_opengl3_loader.h b/backends/imgui_impl_opengl3_loader.h
index a077751c9..1fc7e762c 100644
--- a/backends/imgui_impl_opengl3_loader.h
+++ b/backends/imgui_impl_opengl3_loader.h
@@ -667,6 +667,10 @@ static GL3WglProc (*glx_get_proc_address)(const GLubyte *);
 static int open_libgl(void)
 {
     libgl = dlopen("libGL.so.1", RTLD_LAZY | RTLD_LOCAL);
+#ifdef __NetBSD__
+    if (!libgl)
+       libgl = dlopen("libGL.so.3", RTLD_LAZY | RTLD_LOCAL);
+#endif
     if (!libgl)
         return GL3W_ERROR_LIBRARY_OPEN;
     *(void **)(&glx_get_proc_address) = dlsym(libgl, "glXGetProcAddressARB");

(libGL.so.3 happens to be MesaLib version 21.3.7 on my NetBSD box - really nothing out of the ordinary.)

[ocornut]

I'll add this change now but it feels rather odd that GL3W wouldn't have something like this already.
As for the proper update/sync to latest GL3W it'll wait until someone can help, hoping the update doesn't break this change.
Either way this change could in theory be submitted to both GL3W main repo and GL3W_stripped.

[ocornut]

Pushed to imgui/ and https://github.com/dearimgui/gl3w_stripped
Didn't push to https://github.com/skaslev/gl3w

I used "libGL.so" as initially suggested: seems a little less "safe" (in the land of Unix OpenGL everything is a minefield) but I feel if there is a problem that's the best way to learn about it, and sooner.

[dpaulat]

This fix does not work properly on some Linux distributions. In Ubuntu 22.04 x86_64 for example, there is a symlink /lib/x86_64-linux-gnu/libGL.so -> libGL.so.1. In openSUSE, there is no such symlink, and only /lib64/libGL.so.1. An attempt to initialize the backend results in: Failed to initialize OpenGL loader!. It seems a more robust solution is needed, to look for libGL.so, libGL.so.1 or libGL.so.3.

[zao]

@dpaulat It's not that clear-cut between distros. It's more that the libGL.so symlink is typically provided by -dev/-devel packages as that's what you need to link against when developing; while when just running software shipped by the distro you only need the versioned libGL.so.X, as that's what they were ultimately linked against at package build time.

[ocornut]

Pushed tentative fix a3eea8a, thanks for reporting!