Bug 110141 - glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03
Summary: glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed420...
Status: RESOLVED NOTOURBUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-16 17:47 UTC by Haxk20
Modified: 2019-03-27 16:06 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Haxk20 2019-03-16 17:47:52 UTC
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.
Comment 1 Parker Reed 2019-03-25 15:22:54 UTC
wlroots from sway is also affected.
Comment 2 Eric Engestrom 2019-03-26 16:48:38 UTC
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?
Comment 3 Daniel Stone 2019-03-26 16:52:20 UTC
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.
Comment 4 Eric Engestrom 2019-03-26 17:20:02 UTC
(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 :]
Comment 5 Adam Jackson 2019-03-26 18:30:16 UTC
(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
Comment 6 LoneVVolf 2019-03-26 21:27:01 UTC
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.
Comment 7 Adam Jackson 2019-03-26 21:45:28 UTC
(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.
Comment 8 Eric Engestrom 2019-03-27 16:06:10 UTC
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.