All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Galbusera <gizero@gmail.com>
To: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Cc: Mathias Rudnik <rudnik.mathias@googlemail.com>,
	Yocto Project <yocto@yoctoproject.org>
Subject: Re: Error do_compile libepoxy
Date: Fri, 19 Jan 2018 17:36:28 +0100	[thread overview]
Message-ID: <CAC+thW1JpGq4p+OhWg-mtxBHwacULiJCvWY7jtxHV5vFkXFDvw@mail.gmail.com> (raw)
In-Reply-To: <cf336aca-3cb1-4e1f-e7fc-601311a7d87b@linux.intel.com>

On Fri, Jan 19, 2018 at 1:32 PM, Alexander Kanavin
<alexander.kanavin@linux.intel.com> 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 "


  reply	other threads:[~2018-01-19 16:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 12:46 Error do_compile libepoxy Mathias Rudnik
2018-01-17 12:53 ` Burton, Ross
2018-01-17 12:58 ` Andrea Galbusera
2018-01-18  8:58   ` Andrea Galbusera
2018-01-18  9:05     ` Alexander Kanavin
2018-01-18 10:00       ` Martin Jansa
2018-01-18 10:57         ` Alexander Kanavin
2018-01-18 13:13       ` Max Krummenacher
2018-01-18 13:41         ` Andrea Galbusera
2018-01-18 13:49           ` Alexander Kanavin
2018-01-19  3:29             ` Andre McCurdy
2018-01-19  7:45               ` Alexander Kanavin
2018-01-19 10:45                 ` Andrea Galbusera
2018-01-19 12:32                   ` Alexander Kanavin
2018-01-19 16:36                     ` Andrea Galbusera [this message]
2018-01-22 13:08                       ` Alexander Kanavin
2018-01-20  9:29                     ` Anuj Mittal
2018-01-20 17:07                       ` Andrea Galbusera
2018-01-21 15:23                         ` Anuj Mittal
2018-01-22  9:12                           ` Andrea Galbusera
2018-01-22 13:59                             ` Trevor Woerner
2018-01-18 14:08       ` Trevor Woerner
2018-01-18 15:05         ` Michael Gloff
2018-01-18 20:48           ` Trevor Woerner
2018-01-19  1:35             ` Michael Gloff
2018-01-18  9:09     ` Burton, Ross
  -- strict thread matches above, loose matches on Subject: below --
2018-01-12 13:39 Mathias Rudnik
2018-01-11 19:18 Mathias Rudnik
2018-01-14 20:05 ` Trevor Woerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC+thW1JpGq4p+OhWg-mtxBHwacULiJCvWY7jtxHV5vFkXFDvw@mail.gmail.com \
    --to=gizero@gmail.com \
    --cc=alexander.kanavin@linux.intel.com \
    --cc=rudnik.mathias@googlemail.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.