[Mesa-dev] [PATCH] pkgconfig: Fix gl.pc when glvnd is enabled

Kyle Brenneman kyle.brenneman at gmail.com
Wed May 30 13:18:27 UTC 2018

On 05/29/2018 12:04 PM, Adam Jackson wrote:
> On Tue, 2018-05-29 at 09:54 -0700, Dylan Baker wrote:
>> Quoting Adam Jackson (2018-05-29 06:50:46)
>>> GL_LIB expands to GLX_mesa, but applications should not link against
>>> that. -lGL is never wrong, just hardcode it.
>> Actually.... There is this really stupid option in the autotools build called
>> --gl-lib-name. We should remove that.
>> Emil and I had also discussed that glvnd should provide the gl.pc file when used
>> instead of mesa. It appears he never got around to that, but it seems like a
>> useful thing to do.
> https://github.com/NVIDIA/libglvnd/pull/86
> Branch is a bit stale but better than reinventing everything.
> Part of the reason I didn't get much further on that is the question of
> distributing the _headers_. It would be a bit awkward if glvnd provided
> the library you link to but not the headers defining its interface -
> though, I guess no more awkward than the current situation. At any rate
> glvnd doesn't install any, and there's no way to generate <GL/gl.h>
> from the Khronos scripts at the moment (it's assumed to be a platform
> implementation detail, and the version in Mesa is just handcoded
> history).
> - ajax
Yeah, the headers versus libraries question is what makes it awkward. 
Libglvnd provides the libraries that an application links against, but 
the header files are basically from the Khronos repository. Treating 
libglvnd as the source for the libraries and the Khronos tree as the 
source for the headers would seem to be the cleanest option, but the 
pkg-config files would have to include the paths to both.

Now that I think about it, though, since the Khronos registry is on 
Github now instead of SVN, maybe a git submodule would work?


More information about the mesa-dev mailing list