On Fri, Jan 19, 2018 at 1:32 PM, Alexander Kanavin
<alexander.kanavin@...> wrote:

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:

Yes! Jussi helped a lot in the past with issues raised by graphic
recipes from meta-raspberrypi, most notably 'userland' (see below)...

- 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

Yes, if I understand correctly, meta-raspberrypi uses either 'mesa' or
'userland' [1]
as providers for virtual/egl, mesa being chosen only for 64bit builds
of raspberrypi3.

PREFERRED_PROVIDER_virtual/egl ?=
"${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa",
"userland", d)}"

BTW I gave the 64bit a spin right now to see if something changed with
mesa instead of userland... and it turned out to build just fine
(tests included).
Nailing it down to something userland is supposed to provide but does
not as expected?

[1] https://github.com/raspberrypi/userland

- "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 point to any in particular so I can have a look at the pattern?

Can you try:
a) disabling x11 PACKAGECONFIG in your local config and see if things build?

Yes, they do. As expected, meson does not find the X11 dependency and
skips building tests...

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.

Nope, below change has no effect. The error is the same as in the
original post (missing symbols from X11/Xlib.h)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index 72167a2..ee9db24 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -20,7 +20,7 @@ REQUIRED_DISTRO_FEATURES = "opengl"
DEPENDS = "util-macros"

PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
-PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
+PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"

EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "