On Mon, 2021-06-07 at 17:25 -0400, bkyleruss...@gmail.com wrote: > By having multiple uninative feeds based on host gcc version (rather than a > single uninative feed for all possible host gcc versions), we avoid a general > class of problems (as first observed in the bug below) where changes in native > gcc don't cause native sstate to regenerate. Below is another example where > this problem is encountered across multiple supported host distros for a given > poky version. > > gcc 6 supports default generation of PIE, which gets enabled between Ubuntu > 16.04 (default gcc 5.4) and 18.04 (default gcc 7.5), both supported distros > of warrior. Consider a native package dependency chain as follows: > > A > / | \ > B C D > > If a complete set of native sstate for the above packages is built prior > to the default PIE change, but a workstation upgrades its distro to a version > that natively compiles PIE by default, the sstate hash is not currently > tainted, > so the newer compiler version will pull from sstate not compiled for PIE. > > For example, if a source change to C causes part of the above chain to rebuild > (C -> A), then this may result in non-PIE sstate (B and D) giving link errors > with A. > > ld: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when > making a PIE object; recompile with -fPIC > ld: final link failed: Nonrepresentable section on output > > This appears to have been considered previously as an option to address > the following bug, but appears to have been set aside only because of > proximity to the end of a release cycle. > > [YOCTO #10441]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10441 This doesn't look quite right? > Signed-off-by: Kyle Russell <bkyleruss...@gmail.com> > --- > meta/lib/oe/utils.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py > index a84039f585..8afe19fd99 100644 > --- a/meta/lib/oe/utils.py > +++ b/meta/lib/oe/utils.py > @@ -426,7 +426,7 @@ def host_gcc_version(d, taskcontextonly=False): > bb.fatal("Can't get compiler version from %s --version output" % > compiler) > > > > > > > > > version = match.group(1) > - return "-%s" % version if version in ("4.8", "4.9") else "" > + return "-%s" % version This is a huge performance penalty to put onto the build unfortunately and I really don't want to do that by default on the autobuilder. We haven't seen many of these errors on the autobuilder and I'm reluctant to take the performance hit on our testing. There were specific issues with gcc 4.8 and 4.9 which required separate sstate. Do we know which gcc version switched the default and can we force older gcc's to use the same default or does it not work? I'm wondering if we could split off a "nopic" verison of sstate for example for the older gccs? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#152765): https://lists.openembedded.org/g/openembedded-core/message/152765 Mute This Topic: https://lists.openembedded.org/mt/83381901/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
