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 <opensou...@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 opensou...@keylevel.com www.keylevel.com _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
