Re: sstate info

[Gary Thomas <gary@mlbassoc.com>]

On 2012-01-13 11:09, Richard Purdie wrote:
> On Fri, 2012-01-13 at 09:53 -0700, Gary Thomas wrote:
>> On 2012-01-13 09:27, Richard Purdie wrote:
>>> On Fri, 2012-01-13 at 15:40 +0000, McClintock Matthew-B29882 wrote:
>>>> On Fri, Jan 13, 2012 at 9:23 AM, Gary Thomas<gary@mlbassoc.com>   wrote:
>>>>>>
>>>>>> You can't just override DATE in local.conf? I don't see the point in
>>>>>> holding off, unless your builds will take till tomorrow to finish?
>>>>>
>>>>>
>>>>> Actually, I didn't think of that.  I also didn't see this message
>>>>> until Friday (the next day) due to some network issues, so it's moot.
>>>>>
>>>>> That notwithstanding, I tried it today (new DATE) and it behaved as
>>>>> I would like.  The only problem was that dbus-1 is still being rebuilt.
>>>>> I compared the siginfo files between the two builds and they are
>>>>> identical, so I don't know why.
>>>>
>>>> Are the hashes the same too?
>>>
>>> I've found the root cause of this problem and have posted a fix on the
>>> OE-Core mailing list.
>>
>> Cool, I'll start testing this now :-)
>
> I've also noticed a problem with gcc being rebuilt. It seems to be from
> do_headerfix() and:
>
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index d014980..3a82720 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -77,6 +77,9 @@ do_headerfix () {
>
>   addtask headerfix after do_unpack before do_patch
>
> +CROSS_TARGET_SYS_DIR[vardepsexclude] = "PN"
> +CROSS_TARGET_SYS_DIR[vardepvalue] = "1"
> +
>   do_configure_prepend () {
>          # teach gcc to find correct target includedir when checking libc ssp support
>          mkdir -p ${B}/gcc
>
> "fixes" it. I merged the other fix but this one needs a little bit more thought. bitbake-diffsigs can also mislead:
>
> $ ls *headerfix*
> gcc-cross-4.6.2+svnr181430-r20.do_headerfix.sigdata.84c0ca9d0fc07438f453910901a222b6
> gcc-cross-initial-4.6.2+svnr181430-r20.do_headerfix.sigdata.84c0ca9d0fc07438f453910901a222b6
> $ bitbake-diffsigs *headerfix*
> Dependency on task gcc-cross_4.6.bb.do_unpack was added
> Dependency on task gcc-cross-initial_4.6.bb.do_unpack was removed

While you're looking at gcc, I noticed something else.  I have
multiple MACHINE configurations which are all the same basic
hardware (OMAP3530), the only difference being kernel settings
and other minor target variations.  As far as things like the
compiler and common ARM tools, they are identical.

I tried sharing the sstate between two of these and for the
most part, all was well - only the truly machine dependent
recipes were rebuilt.  Except for gcc-cross-4.6.2 which seems
to have a dependency on the MACHINE variable.  This cascaded
into also building a few other packages (glib, libtool, shadow?
and udev)  [note: I was building a board with SDK tools which
may have brought some of these in].  Does this seem reasonable
to you?  I would hope that these packages, which are placed
in the architecture (armv7a-vfp-neon-amltd-linux-gnueabi) tree
should *not* depend on MACHINE.

Thanks for your help with this.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------