Commit b01524fff05eef66e8cd24f1c5aacefed4209f03 disabled building glesv2 when GLVND is built. This causes multiple issues when building stuff like mutter. Issue is that glesv2.pc is used to determine if system supports GLESv2. An temporary solution is to revert this commit and delete libGLESv2.so in packaging as we used to.
wlroots from sway is also affected.
I'm really tempted to close this as NOTOURBUG, as it's the provider of a library that should claim to provide it (ie. GLVND in this case), but if I understand correctly, glesv2.pc isn't actually used for its contents but rather just as a "does this file exist" check. The thing I don't understand though is: why? What does mutter or wlroots do with this information? In a non-GLVND environment, you compile Mesa with things enabled or not, and you get .so and .pc files that tell you what you have and can use, but in a GLVND environment this information would have to be per-vendor, which a generic `gles2.pc` file cannot give. Say, for instance, that you have the proprietary NVIDIA driver and Mesa on your system. NVIDIA provides GLES 1 & 2, and Mesa is compiled with only GLES 1. You won't have gles2.pc, but GLVND provides libGLESv2.so, and it would be able to provide an actual context thanks to the NVIDIA driver. And what about gles1.pc, should NVIDIA or Mesa provide this file? They wouldn't be able to both provide it, so how would you decide who does? So again, I really don't understand the meaning that's given to "does gles2.pc exists?". Am I missing something?
Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to get the cflags/libs/etc for those libraries. It would be great if GLVND actually shipped them.
(In reply to Daniel Stone from comment #3) > Mutter, wlroots, Weston, and quite a few others, use egl.pc and glesv2.pc to > get the cflags/libs/etc for those libraries. It would be great if GLVND > actually shipped them. If that's the information that's being used, than yeah that's a definite NOTOURBUG :]
(In reply to Eric Engestrom from comment #2) > So again, I really don't understand the meaning that's given to "does > gles2.pc exists?". Am I missing something? It means "can I link against GLES2's library, and if so, how". This really is something glvnd ought to provide. See also https://github.com/NVIDIA/libglvnd/pull/86
Before https://cgit.freedesktop.org/mesa/mesa/commit/?id=b01524fff05eef66e8cd24f1c5aacefed4209f03 mesa built with glvnd support did provide the gles pkgconfig files. After that commit mesa built with glvnd support doesn't provide them anymore. IF mesa developers feel that these files should be provided by glvnd, then it seems logical that mesa devs inform glvnd devs of that position.
(In reply to LoneVVolf from comment #6) > IF mesa developers feel that these files should be provided by glvnd, then > it seems logical that mesa devs inform glvnd devs of that position. My "see also" link in comment #5 was exactly me telling glvnd of that position, yes.
OK, closing this. Ajax provided NVIDIA with a fix for GLVND 3 years ago (I wasn't aware, thanks! :), but they haven't done anything yet. Everyone who Cc'ed yourself here, I'm assuming you have a stake in this issue. I recommend you go on https://github.com/NVIDIA/libglvnd/pull/86 and put pressure on NVIDIA to accept the fix (or come up with something else if they prefer) :)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.