[yocto] Error do_compile libepoxy

[Anuj Mittal]

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.

> 
>> +                   ${@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.
>