Re: [OE-core] [PATCH] lib: oe: utils: always append host gcc version to NATIVELSBSTRING

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Mon, 2021-06-07 at 18:49 -0400, Kyle Russell wrote:
> On Mon, Jun 7, 2021 at 5:43 PM Richard Purdie <richard.purdie@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