[meta-freescale] mesa-dri vs amd-gpu-x11-bin-mx51

[Otavio Salvador]

On Sat, Jan 12, 2013 at 4:00 PM, Eric Bénard <eric at eukrea.com> wrote:
> Le Sat, 12 Jan 2013 15:52:46 -0200,
> Otavio Salvador <otavio at ossystems.com.br> a écrit :
>
>> On Sat, Jan 12, 2013 at 3:49 PM, Eric Bénard <eric at eukrea.com> wrote:
>> > Le Sat, 12 Jan 2013 17:54:13 +0200,
>> > Andrei Gherzan <andrei at gherzan.ro> a écrit :
>> >
>> >> On Sat, Jan 12, 2013 at 4:15 PM, Otavio Salvador <otavio at ossystems.com.br>wrote:
>> >>
>> >> > On Sat, Jan 12, 2013 at 11:59 AM, Eric Bénard <eric at eukrea.com> wrote:
>> >> > > Hi,
>> >> > >
>> >> > > has anyone here already seen this messages ?
>> >> >
>> >> > Yes; I started checking it but I still do not have an absolute answer
>> >> > to how to fix it.
>> >> >
>> >> > The problem is xserver-xorg (when it has glx enabled) it depends on
>> >> > mesa-dri. Both mesa-dri and GPU package libraries (the mx5 and mx6
>> >> > ones) provide same (theorical) functionality of mesa-dri, libraries
>> >> > and (most) headers leading to those errors.
>> >> >
>> >> > I did check how Xorg is compiled in LTIB and it doesn't has glx
>> >> > enabled so my idea is to disable glx in Xorg and try to go this route.
>> >> > This would allow for a clean build at cost of making xserver-xorg
>> >> > machine specific. Do you have any other idea?
>> >> >
>> >>
>> >> Why do you need glx after all? We don't have opengl for imx53 right?
>> >> And about the fix. Xorg with glx should  depend on virtual/libgl (or gl)
>> >> not mesa-dri.
>> >>
>> > mesa-dri provides virtual/libgl which can explain why we find it here.
>>
>> In fact mesa provides all them (GL ES2 and GL ES1 too).
>
> yes, I was in Andrei's email context here.
>
> meta-ti has the following lines in libgles-omap3.inc :
> PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2"
>
> RREPLACES_${PN} = "libegl libgles1 libgles2"
> RREPLACES_${PN}-dev = "libegl-dev libgles1-dev libgles2-dev"
> RREPLACES_${PN}-dbg = "libegl-dbg"
>
> note they have the RREPLACES which are not in meta-fsl-arm's recipes.

Makes sense; but this fixes rootfs problem, not sysroot conflict. My
mean concern here is now it behave in concurrent build?

Let's say:

- xserver-xorg building (so mesa-dri installed at sysroot)
- qt4-x11 build start (so will install amd/vivante libraries at sysroot)

As we don't have individual sysroot for every package in build, this
is something that I don't know the end result.

So I think the right fix is to get rid of glx for mx5 and make
xserver-xorg glx to build with vivante libraries  for mx6.

What do you think?



--
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br