[yocto] Error do_compile libepoxy

[Andrea Galbusera]

Hi Anuj,

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