Issues with gcc 4.8 sstate "contamination" on the autobuilder

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

W dniu 30.05.2013 18:45, Richard Purdie pisze:

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