On Mon, 2021-06-07 at 18:49 -0400, Kyle Russell wrote: > On Mon, Jun 7, 2021 at 5:43 PM Richard Purdie > <richard.pur...@linuxfoundation.org> wrote: > > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10441 > > > > This doesn't look quite right? > > > > > Yes, that's the one. I assumed this was what you meant by, "Another option > would > be to have multiple uninative feeds based on gcc version rather than a single > uninative one."
That is effectively what the code ended up doing and why 4.8 and 4.9 are split out. We only wanted to separate out the specific versions with issues as we wanted to allow reuse where we could. > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10441#c1 > > > 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. > > > > I realize this is not ideal, but I guess the trade-off is dealing with these > issues > as they arise on a case-by-case basis. If they were many issues arriving that might be what we'd have to do but so far I've not seen reports of that many... > > > 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? > > > > > gcc 6 introduced an --enable-default-pie configure option, but I'm not > exactly sure where > between Ubuntu 16.04 and Ubuntu 18.04 they picked that configure option up. > Since packages > based on the older gcc already exist in sstate, I think we would have to > force the newer > behavior on each affected package. > > I realize we can just swizzle the compiler flags on the affected packages to > make things happy, > but it seemed like this approach had at least been considered before, so I > thought I would at least > get some feedback. As Andrea points out, we did fix this with a global include file which should have handled the issue. Are you using a release which doesn't have that or not using the include through your own custom distro? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#152774): https://lists.openembedded.org/g/openembedded-core/message/152774 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] -=-=-=-=-=-=-=-=-=-=-=-
