I'll try to recap a little bit but, please, forgive my ignorance in
graphics stacks and libraries.
Disclaimer: mostly working on headless systems... my bad!
This is what I think I understand here (remember I test building poky
+ meta-raspberrypi):
* libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
on virtual/X11 when this is available in DISTRO_FEATURE
* the latter is the case for poky which is the DISTRO I'm building
for. This gives i.e. a populated recipe-sysroot/usr/include/X11
* upstream meson.build conditionally builds tests if X11 is
available... so we expect they should build fine in this case
* compile fails on test/egl_common.c which does not explicitly include
X11/Xlib.h by itself. Doing so moves things forward but, to me, does
not seem to be the right thing to do.
Is this correct to assume that the upstream tested usecases are
probably getting the include otherwise, maybe conditionally as Alex
initially suggested. If so, where should we look for the missing
pieces?
I'm similarly ignorant about this stuff (our resident graphics stack
expert Jussi Kukkonen left a few months ago), but let's consider the
build files:
- the offending tests are wrapped in "if build_egl and build_x11_tests"
- build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
available
- "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
DISTRO_FEATURES:
PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
This is where I think the configuration is not quite right. Instead of
virtual/libx11, it should say virtual/libgl. And if that dependency
cannot be satisfied, then the x11 option should be altogether disabled
in the distro/local config (in poky mesa provides virtual/libgl). At
least that's how it's configured in many other recipes throughout oe-core.
Can you try:
a) disabling x11 PACKAGECONFIG in your local config and see if things build?
b) changing the dependency in that option to virtual/libgl and see what
kind of error you get, if any. I guess this is the right fix after all.
Alex
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
