[meta-freescale] mx6q: fix virtual/libgl dependencies

[Otavio Salvador]

On Thu, Jul 18, 2013 at 9:03 AM, Simon Braunschmidt <sb at emlix.com> wrote:
> Hi
>
> I am still new to Yocto, so bear with me if some of the following
> is not correct, you are welcome to open my eyes though ;-)
>
> I have observed a problem to compile libglu in a configuration
> for cgtqmx6 (imx6, from meta-fsl-arm-extra).
> For a completely clean rebuild, sometimes compilation succeeds,
> but sometimes it fails, not finding libGL for linking:
>
> /home/devel/yocto/ ... /arm-poky-linux-gnueabi/4.8.1/ld: cannot find -lGL
> collect2: error: ld returned 1 exit status
>
> It looks like a race condition, sometimes the package/task providing
> libGL is ready when libglu is compiled, sometimes not.
>
> Some findings:
>
> - meta-fsl-arm/recipes-graphics/mesa/mesa_9.1.3.bbappend is used to
>   delete libGL.* after compilation of mesa
>
> - ./recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.0.35-4.0.0.bb, via
>   gpu-viv-bin-mx6q.inc, provides its own version of libGL
>
> - gpu-viv-bin-mx6q does not advertise "virtual/libgl" in "PROVIDES +="
>
> - but mesa (via mesa.inc) does:
>   PROVIDES = "virtual/libgl virtual/libgles1 virtual/libgles2 virtual/egl"
>
> - so the statement in imx-base.inc
>    PREFERRED_PROVIDER_virtual/libgl_mx6 ?= "gpu-viv-bin-mx6q"
>   does not have effect, because mesa is still the only provider of virtual/libgl
>
> - packages depending on virtual/libgl only get mesa, which will not contain
>   the libGL library
>
> - in fact, we still use the gl headers from mesa, but the binary blob library
>   from gpu-viv-bin-mx6q (i have no words to describe this ...),
>         so a package compiling against GL needs both mesa and gpu-viv-bin-mx6q
>
> - so i suggest having gpu-viv-bin-mx6q depend on mesa to draw in the
>   gl header package, advertising "virtual/libgl" for gpu-viv-bin-mx6q
>   via "PROVIDES +=" and not advertising virtual/libgl for mesa via the
>   .bbappend file
>
>
> Would the following patch be appropriate?

It does and your analysis is right.

John, please give this patch a try as it does seem to fix your issue
at https://bugzilla.yoctoproject.org/show_bug.cgi?id=4850

Simon,

Can you please put a note about this issue in your commit log? like:

Fixes [YOCTO #4850].


--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750