Message ID | 20241222162234.2411262-5-tom.hochstein@oss.nxp.com |
---|---|
State | New |
Headers | show |
Series | [v3,1/5] pkgconfig: Add pkg-config-native to SDK | expand |
On Sun, 2024-12-22 at 10:22 -0600, Tom Hochstein via lists.openembedded.org wrote: > Building weston with core-image-weston SDK fails: > ``` > ../libweston/renderer-gl/gl-shader-config-color-transformation.c:29:10: fatal error: GLES3/gl3.h: No such file or directory > 29 | #include <GLES3/gl3.h> > | ^~~~~~~~~~~~~ > ``` > > Both GLES2 and GLES3 implementations are contained in libGLESv2.so.2, > which is packaged in libgles2-mesa. However, the headers are split > between libgles2-mesa-dev and libgles3-mesa-dev, which is why the > GLES3 headers end up missing in the SDK sysroot. > > Add a dependency so the GLES3 headers are properly associated with > the GLES3 implementation. > > Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> > --- > meta/recipes-graphics/mesa/mesa.inc | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc > index 9fdf496e8b..84490158f1 100644 > --- a/meta/recipes-graphics/mesa/mesa.inc > +++ b/meta/recipes-graphics/mesa/mesa.inc > @@ -233,6 +233,10 @@ DEV_PKG_DEPENDENCY = "" > # development package of libgles3. > RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev" > > +# GLES2 and GLES3 implementations are packaged in a single library in libgles2-mesa. > +# Add a dependency so the GLES3 dev package is associated with its implementation. > +RDEPENDS:libgles2-mesa-dev += "libgles3-mesa-dev" > + > RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc spirv-tools', '', d)}" This doesn't quite make sense to me. The line above that RDEPENDS is adding a dependency in the opposite direction and will effectively make one package uninstallable without the other. The question is does the libgles2-mesa-dev package need the libgles3- mesa-dev package? If not, this is not the right way to solve the problem you're seeing. Cheers, Richard
On 12/23/2024 5:28 AM, Richard Purdie wrote: >> >> +# GLES2 and GLES3 implementations are packaged in a single library in libgles2-mesa. >> +# Add a dependency so the GLES3 dev package is associated with its implementation. >> +RDEPENDS:libgles2-mesa-dev += "libgles3-mesa-dev" >> + >> RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc spirv-tools', '', d)}" > > This doesn't quite make sense to me. The line above that RDEPENDS is > adding a dependency in the opposite direction and will effectively make > one package uninstallable without the other. > > The question is does the libgles2-mesa-dev package need the libgles3- > mesa-dev package? If not, this is not the right way to solve the > problem you're seeing. > Does this work better, signifying that libgles2-mesa contains libgles3- mesa? +RDEPENDS:libgles2-mesa += "libgles3-mesa" +ALLOW_EMPTY:libgles3-mesa = "1" Tom
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index 9fdf496e8b..84490158f1 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -233,6 +233,10 @@ DEV_PKG_DEPENDENCY = "" # development package of libgles3. RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev" +# GLES2 and GLES3 implementations are packaged in a single library in libgles2-mesa. +# Add a dependency so the GLES3 dev package is associated with its implementation. +RDEPENDS:libgles2-mesa-dev += "libgles3-mesa-dev" + RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl', 'libclc spirv-tools', '', d)}" PACKAGES =+ "libegl-mesa libegl-mesa-dev \
Building weston with core-image-weston SDK fails: ``` ../libweston/renderer-gl/gl-shader-config-color-transformation.c:29:10: fatal error: GLES3/gl3.h: No such file or directory 29 | #include <GLES3/gl3.h> | ^~~~~~~~~~~~~ ``` Both GLES2 and GLES3 implementations are contained in libGLESv2.so.2, which is packaged in libgles2-mesa. However, the headers are split between libgles2-mesa-dev and libgles3-mesa-dev, which is why the GLES3 headers end up missing in the SDK sysroot. Add a dependency so the GLES3 headers are properly associated with the GLES3 implementation. Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> --- meta/recipes-graphics/mesa/mesa.inc | 4 ++++ 1 file changed, 4 insertions(+)