On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <g...@mlbassoc.com> wrote:
> If I run a build where the kernel package is brought in via > sstate, tmp/work-shared (in particular the kernel-source tree) > is not populated. This will break at least these recipes: > meta-fsl-arm/recipes-multimedia/gstreamer/gst-fsl-plugin_4.0.2.bb > meta-fsl-arm/recipes-multimedia/alsa/fsl-alsa-plugins_1.0.25.bb > > These programs reference the kernel includes directly for some > ARM/i.MX specific headers (e.g. <linux/mxcfb.h>). These headers > are not part of the mainline kernel which is used to create the > kernel headers that populates tmp/sysroots, so the build fails. > Note: I'm not sure of the mechanism that lets these programs > peek into the kernel build (I looked at them but nothing jumped > out), but they do build find if the kernel is actually built > and not just brought in by sstate. > > Is this an error & if so, which recipe is at fault? The FSL > recipes, or the new kernel build/classes? > Per commit 46cdaf1c7bc597735d926af6a46f9483f7e57ce5 (oe-core 6a1ff0e7eacef595738f2fed086986fd622ec32a), you need to add this if you depend on the sources: do_configure[depends] += "virtual/kernel:do_shared_workdir" -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto