[yocto] Possible Cedartrail PVR build race

Chris Tapp opensource at keylevel.com
Thu Mar 21 14:27:56 PDT 2013


On 21 Mar 2013, at 19:22, Chris Tapp wrote:

> Hi Ross,
> 
> On 21 Mar 2013, at 09:09, Burton, Ross wrote:
> 
>> On 21 March 2013 09:01, Chris Tapp <opensource at keylevel.com> wrote:
>>> I think I have a build race condition for a project:
>>> 
>>> 1) Using the meta-intel/cedartrail BSP;
>>> 2) Building under Danny 8.0;
>>> 3) Custom image;
>>> 4) Custom task;
>>> 5) OpenGLES application which runs under 'X'.
>>> 
>>> If I do a clean build (i.e. after deleting tmp/ sstate-cache/) then my application produces 'fuzz' on the screen - some vertical strips visible, but nothing recognisable.
>>> 
>>> If I then 'cleanall' the image, task and application and rebuild the image I get an image with an application that works as expected.
>>> 
>>> I suspect this is something to do with some warning messages I get during the clean build:
>>> 
>>> WARNING: The recipe is trying to install files into a shared area when those files already exist. Those files are:
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/KHR/khrplatform.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/gl.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/egl.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glext.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES/glplatform.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/egl.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglplatform.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/EGL/eglext.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2platform.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/include/GLES2/gl2ext.h
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so.2
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv2.so
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libGLESv1_CM.so.1
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so.1
>>>  /media/SSD-RAID/build-danny-cedartrail/tmp/sysroots/cedartrail/usr/lib/libEGL.so
>>> 
>>> Is there something I can add to my image/task/application .bb to prevent this?
>> 
>> If you were using master you'd see some more useful output, such as
>> the recipes that are conflicting.  I'm 99% certain that in this case
>> it's pvr-cdt-driver and mesa-dri.  On CDT you really don't want
>> mesa-dri.
>> 
>> I suspect this is coming through the xserver-xorg package which
>> defaults to enabling GLX, which requires mesa-dri.  Inspecting your
>> dependency tree with depexp should confirm this.  Presumably your GLES
>> application is using EGL and not GLX?
>> 
>> I'm always forgetting the exact syntax here, but try setting
>> PACKAGECONFIG_pn-xserver-xorg = "udev" in your local.conf.  This
>> should disable the glx options, and drop the mesa-dri dependency.
> 
> Thanks, that's helped a bit. depexp was showing:
> 
> xserver-xorg, libva, mesa-dri, packagegroup-core-x11-xserver.
> 
> Your setting gets rid of 'xserver-xorg' and I assume 'mesa-dri' will go when mesa-dri isn't needed.
> 
> So, that just leaves libva and the packagegroup.


The packagegroup is a problem:

| error: Failed dependencies:
| 	xserver-xorg-extension-glx is needed by packagegroup-core-x11-xserver-1.0-r39.cedartrail
| 	xserver-xorg-extension-dri is needed by packagegroup-core-x11-xserver-1.0-r39.cedartrail
| ERROR: Function failed: do_rootfs (see /media/SSD-RAID/build-danny-cedartrail/tmp/work/cedartrail-poky-linux/opty4gles-image-1.0-r0/temp/log.do_rootfs.10973 for further information)



Chris Tapp

opensource at keylevel.com
www.keylevel.com






More information about the yocto mailing list