[yocto] Error do_compile libepoxy

[Andrea Galbusera]

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...

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