Issues with gcc 4.8 sstate "contamination" on the autobuilder

Issues with gcc 4.8 sstate "contamination" on the autobuilder

[Richard Purdie]

I want to make people aware we're seeing some issues with gcc 4.8 on the
autobuilder.

gcc is a whitelisted dependency in sstate so it is *not* accounted for
in the sstate checksums.

This means if you run a build with gcc 4.8, switch to 4.7 and then run a
similar build, you can reuse sstate between the two. This has lead to
failures on the autobuilder recently which have been rather confusing
and is why the weekly test report is as red.

I want to highlight the problem and make it clear this isn't an sstate
bug, the sstate class is explicitly allowing this as things stand.

In normal usage, you don't want a small change to gcc changing your
world around so the class is probably ok as it is but we are going to
have to be careful with builds going forwards. 1.5M1 may need clean
sstate, just to be sure.

Cheers,

Richard

Re: Issues with gcc 4.8 sstate "contamination" on the autobuilder

[Marcin Juszkiewicz]

W dniu 30.05.2013 18:45, Richard Purdie pisze:
> I want to make people aware we're seeing some issues with gcc 4.8 on the
> autobuilder.

When we are at sstate and gcc...

I noticed recently that libunwind may break gcc builds:

https://bugs.launchpad.net/linaro-oe/+bug/1183087

The issue exists only when libunwind was built before gcc was started.

To reproduce:

bitbake -ccleansstate gcc libunwind
bitbake libunwind
bitbake gcc

Did not yet found proper working solution.

Re: Issues with gcc 4.8 sstate "contamination" on the autobuilder

[Mark Hatle]

On 5/30/13 12:22 PM, Marcin Juszkiewicz wrote:
> W dniu 30.05.2013 18:45, Richard Purdie pisze:
>> I want to make people aware we're seeing some issues with gcc 4.8 on the
>> autobuilder.
>
> When we are at sstate and gcc...
>
> I noticed recently that libunwind may break gcc builds:
>
> https://bugs.launchpad.net/linaro-oe/+bug/1183087
>
> The issue exists only when libunwind was built before gcc was started.
>
> To reproduce:
>
> bitbake -ccleansstate gcc libunwind
> bitbake libunwind
> bitbake gcc
>
> Did not yet found proper working solution.

Just an FYI -- I've reproduced the same issue here for an qemux86_64 machine 
using stock oe-core.

(Similarly, I don't have a solution either.)

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: Issues with gcc 4.8 sstate "contamination" on the autobuilder

[Mark Hatle]

On 5/31/13 10:12 AM, Mark Hatle wrote:
> On 5/30/13 12:22 PM, Marcin Juszkiewicz wrote:
>> W dniu 30.05.2013 18:45, Richard Purdie pisze:
>>> I want to make people aware we're seeing some issues with gcc 4.8 on the
>>> autobuilder.
>>
>> When we are at sstate and gcc...
>>
>> I noticed recently that libunwind may break gcc builds:
>>
>> https://bugs.launchpad.net/linaro-oe/+bug/1183087
>>
>> The issue exists only when libunwind was built before gcc was started.
>>
>> To reproduce:
>>
>> bitbake -ccleansstate gcc libunwind
>> bitbake libunwind
>> bitbake gcc
>>
>> Did not yet found proper working solution.
>
> Just an FYI -- I've reproduced the same issue here for an qemux86_64 machine
> using stock oe-core.
>
> (Similarly, I don't have a solution either.)

Forgot to add in my case the sstate cache had nothing to do with it.  If 
libunwind is built first, then gcc appears to fail.  Cleaning both and 
rebuilding gcc caused it to work.

--Mark