[yocto] Help needed understanding do_rootfs error

[Chris Tapp]

On 15 Jun 2012, at 07:01, Tomas Frydrych wrote:

> Hi,
> 
> On 14/06/12 22:42, Chris Tapp wrote:
>> On 14 Jun 2012, at 21:44, Chris Tapp wrote:
>> 
>>> The log for do_rootfs is showing: < snip > error: Failed
>>> dependencies: libGL.so.1 is needed by libglut3-7.11-r13.2.armv6 
>>> libGL.so.1 is needed by column-wallboard-1.0-r1.armv6 libGL.so.1 is
>>> needed by libglu1-7.11-r13.2.armv6
>>> 
>>> libGL is showing in the work area, so I think I just need to add a
>>> dependency. But what and where?
> 
> There should be no GL on RPI at all, the HW drivers only support GLES/2,
> so the short answer is you can't pull in packages that require GL (in
> theory you could build mesa with the software rasterizer, but you will
> get unacceptable performance, and in the presence of GLES2 that makes no
> sense anyway).

No, it works just fine. I had somehow got two conflicting versions pulled in at the same time (sorted by hiding the one I didn't expect and seeing what complained when I tried to build). Performance isn't great, but using Xfbdev works as fast (by 'eye') as it does on the unaccelerated hardware that the build was originally designed for. I've no plans to rewrite to use GLES (at this time) as the development version uses SDL with DirectFB (which is supposed to be getting ported to the RPi). The SDL version already works acceptably without DirectFB.

> Incidentally, the GLES libs are not currently packaged by
> meta-raspberrypi, I submitted a pull request for this yesterday.

Thanks, that will be nice. I want to look at GLES for other things. May even update what I already have if it shows significant performance advantages (which it should). Looks like DirectFB has some sort of GLES support, so I also need to look at that.

>> Ah, there was an ERROR right at the start of the build saying there
>> were multiple providers for virtual/libgl (mesa-xlib, mesa-dri). How
>> can I track down the cause of this? Building virtual/libgl doesn't
>> get this error - it only shows when I build the full image.
> 
> In general, mesa-xlib provides a software GLX emulation, mesa-dri
> provides glx based on the GLX extension and each machine conf needs to
> choose a preferred provider for virtual/libgl to get rid of this error.
> However, in the RPI case, no virtual/libgl should be getting pulled into
> the images.


It gets pulled in because that's what I've asked for in my image ;-) I did have a preferred provider, but, as I said above, I found an error that meant it wasn't working as expected.

Chris Tapp

opensource at keylevel.com
www.keylevel.com