* tmp/work-shared and sstate @ 2015-02-10 17:28 Gary Thomas 2015-02-10 18:13 ` Christopher Larson 0 siblings, 1 reply; 5+ messages in thread From: Gary Thomas @ 2015-02-10 17:28 UTC (permalink / raw) To: Yocto Project, meta-freescale@yoctoproject.org 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? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-freescale] tmp/work-shared and sstate 2015-02-10 17:28 tmp/work-shared and sstate Gary Thomas @ 2015-02-10 18:13 ` Christopher Larson 0 siblings, 0 replies; 5+ messages in thread From: Christopher Larson @ 2015-02-10 18:13 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale@yoctoproject.org, Yocto Project [-- Attachment #1: Type: text/plain, Size: 1414 bytes --] On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <gary@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 [-- Attachment #2: Type: text/html, Size: 2139 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tmp/work-shared and sstate @ 2015-02-10 18:13 ` Christopher Larson 0 siblings, 0 replies; 5+ messages in thread From: Christopher Larson @ 2015-02-10 18:13 UTC (permalink / raw) To: Gary Thomas; +Cc: meta-freescale@yoctoproject.org, Yocto Project [-- Attachment #1: Type: text/plain, Size: 1414 bytes --] On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <gary@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 [-- Attachment #2: Type: text/html, Size: 2139 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-freescale] tmp/work-shared and sstate 2015-02-10 18:13 ` Christopher Larson (?) @ 2015-02-10 18:35 ` Gary Thomas 2015-02-11 11:23 ` Gary Thomas -1 siblings, 1 reply; 5+ messages in thread From: Gary Thomas @ 2015-02-10 18:35 UTC (permalink / raw) To: yocto On 2015-02-10 11:13, Christopher Larson wrote: > > On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <gary@mlbassoc.com <mailto:gary@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 <http://gst-fsl-plugin_4.0.2.bb> > meta-fsl-arm/recipes-__multimedia/alsa/fsl-alsa-__plugins_1.0.25.bb <http://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" > -- Thanks, I'm checking now to see if this fixes the problem. One thing I noted is I added that line to the two recipes in question. When I [re]built my target image with these changes in a tree that I had just built using only sstate, it kicked off a ton of tasks (~6000!), and it seems that it's now rebuilding everything from scratch, not just unpacking the kernel. Once this finishes, I'll try another rebuild from sstate to see how that works, but it sure looks like it's doing a lot more than necessary. Is this to be expected? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [meta-freescale] tmp/work-shared and sstate 2015-02-10 18:35 ` [meta-freescale] " Gary Thomas @ 2015-02-11 11:23 ` Gary Thomas 0 siblings, 0 replies; 5+ messages in thread From: Gary Thomas @ 2015-02-11 11:23 UTC (permalink / raw) To: yocto On 2015-02-10 11:35, Gary Thomas wrote: > On 2015-02-10 11:13, Christopher Larson wrote: >> >> On Tue, Feb 10, 2015 at 10:28 AM, Gary Thomas <gary@mlbassoc.com <mailto:gary@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 <http://gst-fsl-plugin_4.0.2.bb> >> meta-fsl-arm/recipes-__multimedia/alsa/fsl-alsa-__plugins_1.0.25.bb <http://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" >> -- > > Thanks, I'm checking now to see if this fixes the problem. > > One thing I noted is I added that line to the two recipes in > question. When I [re]built my target image with these changes > in a tree that I had just built using only sstate, it kicked > off a ton of tasks (~6000!), and it seems that it's now rebuilding > everything from scratch, not just unpacking the kernel. Once this > finishes, I'll try another rebuild from sstate to see how that works, > but it sure looks like it's doing a lot more than necessary. > > Is this to be expected? I'm not sure why this complete rebuild happened (sadly, it took more than 8 hours...) When it completed, I tried another rebuild from sstate only and things worked as expected with everything coming in from sstate. One concern though - the kernel package seems to have been completely rebuilt, not just the work-shared tree being repopulated. Is this correct? Thanks for the swift answer to this problem. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-02-11 11:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-02-10 17:28 tmp/work-shared and sstate Gary Thomas 2015-02-10 18:13 ` [meta-freescale] " Christopher Larson 2015-02-10 18:13 ` Christopher Larson 2015-02-10 18:35 ` [meta-freescale] " Gary Thomas 2015-02-11 11:23 ` Gary Thomas
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.