From: Gary Thomas <gary@mlbassoc.com>
To: yocto@yoctoproject.org
Subject: Re: [meta-freescale] tmp/work-shared and sstate
Date: Tue, 10 Feb 2015 11:35:28 -0700 [thread overview]
Message-ID: <54DA4F70.7030702@mlbassoc.com> (raw)
In-Reply-To: <CABcZAN=2uiE8=fmTJOxvq3zsbaL5W9BwS+r7zxN2bMtChQL7vA@mail.gmail.com>
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
------------------------------------------------------------
next prev parent reply other threads:[~2015-02-10 18:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Gary Thomas [this message]
2015-02-11 11:23 ` [meta-freescale] " Gary Thomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DA4F70.7030702@mlbassoc.com \
--to=gary@mlbassoc.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.