On Fri, Jan 19, 2018 at 8:45 AM, Alexander Kanavin <alexander.kana...@linux.intel.com> wrote: > On 01/19/2018 05:29 AM, Andre McCurdy wrote: >>> >>> Note that this same test does build fine in poky, so disabling the tests >>> is >>> not a good fix. You should figure out what is about the non-poky EGL >>> headers >>> that is causing the failure, and whether you need to configure the >>> provider >>> of those headers differently, or add missing dependencies etc. >> >> >> Upstream documents that the test suite relies on X11: >> >> https://github.com/anholt/libepoxy/blob/1.4.3/README.md#building >> >> So disabling the test suite for targets without X11 seems like a >> perfectly reasonable approach. > > > The meson.build files already have guards for lack of X11 around the test > files that are failing here. It looks like in this particular configuration > meson erroneously detects that X11 is present, when it's not. > > Alex
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? Andrea -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
