[yocto] Possible Cedartrail PVR build race

[Burton, Ross]

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.

Ross