Closed haasn closed 7 months ago
Well I mention gl.pc as a means of pulling in the appropriate header path, since the headers in question are from OpenGL / Mesa.
Yes, the issue is glad looking for the OpenGL headers. Being as glad appears to be just a set of headers as some sort of abstraction.
I don't see how (at the moment) it would pass on such an appropriate header path to libplacebo at the moment for it's possible knowledge of where the OpenGL / Mesa implementation is located.
Not sure what's going on here, it seems that this header does not exist on some platforms.
I had that before there was also issues where the platform provided one was outdated and didn't have the necessary symbols, that's why I started including it in the glad output. A header only build embeds it and normal one generates also the dependencies. Should just be able to take the entire glad output.
The headers very much exist on the platforms. That isn't the issue.
But headers have to be able to be found, not make assumptions as is typical of a Linux build environment.
glad/egl.h has (which libplacebo src/opengl/common.h pulls in)..
#define GLAD_GL
#define GLAD_GLES2
#include <glad/gl.h>
#include <glad/egl.h>
#ifndef __eglplatform_h_
#define __eglplatform_h_
/*
** Copyright 2007-2020 The Khronos Group Inc.
** SPDX-License-Identifier: Apache-2.0
*/
/* Platform-specific types and definitions for egl.h
*
* Adopters may modify khrplatform.h and this file to suit their platform.
* You are encouraged to submit all modifications to the Khronos group so that
* they can be included in future versions of this file. Please submit changes
* by filing an issue or pull request on the public Khronos EGL Registry, at
* https://www.github.com/KhronosGroup/EGL-Registry/
*/
#include <KHR/khrplatform.h>
I don't understand the problem, glad gives you the necessary header dependencies, you just add them to the include path, like you add glad to the include path (it's the same one).
@Dav1dde you can see the error here https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1299859
The file is generated though.
Okay, it can't find the header, then there is a missing include.
Not sure how this is related to glad, glad recognizes the dependency and also outputs the necessary header, it has no control over the compiler include flags.
glad gives you the necessary header dependencies
Where does it put this information?
you can see the error here gitlab.alpinelinux.org/alpine/aports/-/jobs/1299859
in this specific case <KHR/khrplatform.h>
would exist if you had mesa-dev
installed as a makedep (because that path can then be found from the default /usr/include
incpath). whether that's intended or not i can't say (does glad depend on the system-provided headers of this?), but it's very easy to fix the build there
Where does it put this information?
Either the include directory contains the headers or it doesn't:
include/glad/gl.h
include/KHR/khrplatform.h
@nekopsykose again, no, glad does specifically include all necessary headers in its output, just check the output directory.
Okay I see, you're generating a header only EGL build and eglplatform now depends on khrplatform but the include is not removed by glad.
Too bad CI didn't catch this, there is a test which would fail, but the test environment has the header installed :(
I'll release a new glad version in the next minutes, sorry for the troubles.
Thanks!
Thanks.
See https://github.com/haasn/libplacebo/issues/246
Not sure what's going on here, it seems that this header does not exist on some platforms. Maybe it needs to be made conditional somehow. The issue poster over there suggests extracting the include path from
gl.pc
, but I am not convinced this is the best solution.