A question of sstate and compilers
I'm trying to isolate a problem that showed up in my builds in the last month. Little has changed in the sources, but the one big change was I moved from GCC/4.9 to GCC/5.x On the surface, this seemed to be a non-consequence, but I have one very subtle corner case that is now broken. In an effort to isolate the issue (I no longer think it was the compiler change), I went back to GCC/4.9. This caused my build (tree) which has existed for many months (the same build tree started in Feb 2016) to basically rebuild everything.
There's the rub - shouldn't the sstate-cache hold all of those old bits and just be able to re-stage? I'm a bit confused about that. Even worse, I switched back to GCC/5.x, didn't touch anything else in my sources or build tree, and now it's off again, [re]building the majority of my packages.
Any explanations? Is this correct behavior?
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 10 lines · Gary Thomas
I'm trying to isolate a problem that showed up in my builds in the last month. Little has changed in the sources, but the one big change was I moved from GCC/4.9 to GCC/5.x On the surface, this seemed to be a non-consequence, but I have one very subtle corner case that is now broken. In an effort to isolate the issue (I no longer think it was the compiler change), I went back to GCC/4.9. This caused my build (tree) which has existed for many months (the same build tree started in Feb 2016) to basically rebuild everything.
Quoted 6 lines
There's the rub - shouldn't the sstate-cache hold all of those old bits and just be able to re-stage? I'm a bit confused about that. Even worse, I switched back to GCC/5.x, didn't touch anything else in my sources or build tree, and now it's off again, [re]building the majority of my packages.
It's possible that there was some other change that caused a rebuild.
bitbake-whatchanged, bitbake -S printdiff, etc will help you chase this if
you want to.
Ross
Quoted 20 lines · Ross
On 30 July 2016 at 09:41, Gary Thomas <[email protected] <mailto:[email protected]>> wrote:
I'm trying to isolate a problem that showed up in my builds in the last month. Little has changed in the sources, but the one big change was I moved from GCC/4.9 to GCC/5.x On the surface, this seemed to be a non-consequence, but I have one very subtle corner case that is now broken. In an effort to isolate the issue (I no longer think it was the compiler change), I went back to GCC/4.9. This caused my build (tree) which has existed for many months (the same build tree started in Feb 2016) to basically rebuild everything.
There's the rub - shouldn't the sstate-cache hold all of those old bits and just be able to re-stage? I'm a bit confused about that. Even worse, I switched back to GCC/5.x, didn't touch anything else in my sources or build tree, and now it's off again, [re]building the majority of my packages.
Quoted 2 lines
It's possible that there was some other change that caused a rebuild. bitbake-whatchanged, bitbake -S printdiff, etc will help you chase this if you want to.
Nothing else changed, I'm sure.
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 2 lines · Gary Thomas
Nothing else changed, I'm sure.
*Something* changed, although it may be something that shouldn't have caused a rebuild (at which point printdiff is useful to find that out).
Ross
Quoted 8 lines · Ross
On 1 August 2016 at 15:26, Gary Thomas <[email protected] <mailto:[email protected]>> wrote:
Nothing else changed, I'm sure.
*Something* changed, although it may be something that shouldn't have caused a rebuild (at which point printdiff is useful to find that out).
I'll try running this and report, but the only thing that changed is the line in local.conf selecting the version of GCC
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------