Re: Error do_compile libepoxy


Andrea Galbusera
 

Hi Anuj,

On Sun, Jan 21, 2018 at 4:23 PM, Anuj Mittal <anuj.mittal@...> wrote:
On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal <anuj.mittal@...> wrote:
On 01/19/2018 08:32 PM, 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:

- 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.
Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
glx depends on gl and x11 so if it is to be enabled, both of them should
be present.

However, x11 without glx and just egl should still be valid configuration.

I think the correct configuration should be:


diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index 72167a2..0043bec 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
"https://github.com/anholt/libepoxy/releases"

inherit meson pkgconfig distro_features_check

-REQUIRED_DISTRO_FEATURES = "opengl"
-
DEPENDS = "util-macros"

+REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
'glx', 'x11', '', d)}"
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \
Did you mean 'opengl x11' or is glx a valid distro feature? I don't
see it mentioned anywhere else...
Oh yes, you're right. I was trying something out & didn't clean before
sending. It should be:

bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'glx', d)

However, I think it'll probably still fail for rpi because I think this
test depends on Xlib.h being included from EGL/eglplatform.h but in case
of "userland", doesn't happen because that include is probably not there.

Can you try an explicit include of Xlib.h in egl_common.c after patching
this recipe? You shouldn't get the GL linking errors after that since we
have now added explicit dependency on virtual/libgl when glx is enabled.
The updated patch seems to work here! libepoxy builds fine along with
tests for raspberrypi3 default configs. All my build turned back to
green. A cascaded failure on gtk+3 I was seeing with the previous
version of your patch went away. Of course, I had to explicitly
include the Xlib.h as you suggested to get past the compile error.
EGL/eglplatform.h from userland has already been causing issues with
missing declarations in the past (see [1] and [2] for some context).
Once more, looking at Khronos registry [3], which I learned being the
right upstream reference for such an header, expected X11 includes are
there, while, as said, they are missing in userland eglplatform.h.
Unfortunately userland community does not seem to be very keen to
update their includes even though Khronos published more up to date
versions. I'll try to follow up with a patch to meta-raspberrypi and
possibly upstream to userland. In the end, I don't think libepoxy is
the right place to explicitly put the change. What's your opinion
here?

I don't have other builds with graphics stacks enabled at hand that I
can test your patch against. Do you think further testing will be
needed before you can submit this patch to oe-core?

[1] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg98209.html
[2] https://github.com/raspberrypi/userland/pull/407
[3] https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h



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

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

I didn't test this on all combinations. Perhaps someone can help test on
rpi?
Thanks, I volunteer to keep testing with rpi configurations, but I
don't understand the realm enough to judge the patch effect on other
scenarios.

Join yocto@lists.yoctoproject.org to automatically receive all group messages.