Future of GCC

Future of GCC

[Gary Thomas]

Now that GCC 4.x is gone, we're left with (currently) 5.4 & 6.1
Is the intention to track these both for a while, or will 5.x
also be gone once things are working with 6.x?

... just wondering where to spend my effort since I'll have to
make my targets (some are very old) work with at least 5.x

Any advice?  Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Future of GCC

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

On 12 July 2016 at 08:57, Gary Thomas <gary@mlbassoc.com> wrote:

> Now that GCC 4.x is gone, we're left with (currently) 5.4 & 6.1
> Is the intention to track these both for a while, or will 5.x
> also be gone once things are working with 6.x?
>
> ... just wondering where to spend my effort since I'll have to
> make my targets (some are very old) work with at least 5.x
>
> Any advice?  Thanks
>

Personally I was thinking that gcc 5.x and 6.x should stay in oe-core for
this cycle, and then drop 5.x after the release.  I'm not the toolchain
owner though so that's just an opinion.

In theory bringing back toolchains isn't rocket science - just copying the
4.x recipes from oe-core prior to their removal into a new layer and
setting GCCVERSION should work.

Ross

[-- Attachment #2: Type: text/html, Size: 1290 bytes --]

Re: Future of GCC

[akuster808]

On 07/12/2016 01:15 AM, Burton, Ross wrote:
> On 12 July 2016 at 08:57, Gary Thomas <gary@mlbassoc.com> wrote:
> 
>> Now that GCC 4.x is gone, we're left with (currently) 5.4 & 6.1
>> Is the intention to track these both for a while, or will 5.x
>> also be gone once things are working with 6.x?
>>
>> ... just wondering where to spend my effort since I'll have to
>> make my targets (some are very old) work with at least 5.x
>>
>> Any advice?  Thanks
>>
> 
> Personally I was thinking that gcc 5.x and 6.x should stay in oe-core for
> this cycle, and then drop 5.x after the release.


Wouldn't that be dropped iff GCC 7.0 is release? or are you saying we
should only have one GCC version?

- armin

I'm not the toolchain
> owner though so that's just an opinion.


> 
> In theory bringing back toolchains isn't rocket science - just copying the
> 4.x recipes from oe-core prior to their removal into a new layer and
> setting GCCVERSION should work.
> 
> Ross
> 
> 
> 

Re: Future of GCC

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On 12 July 2016 at 22:14, akuster808 <akuster808@gmail.com> wrote:

> > Personally I was thinking that gcc 5.x and 6.x should stay in oe-core for
> > this cycle, and then drop 5.x after the release.
>
>
> Wouldn't that be dropped iff GCC 7.0 is release? or are you saying we
> should only have one GCC version?
>

Well, depends on the adoption and migration problems.  I don't think we
should carry three versions, and ideally one, but two is acceptable to ease
migration.

Ross

[-- Attachment #2: Type: text/html, Size: 891 bytes --]

Re: Future of GCC

[akuster808]

On 07/12/2016 02:24 PM, Burton, Ross wrote:
> On 12 July 2016 at 22:14, akuster808 <akuster808@gmail.com> wrote:
> 
>>> Personally I was thinking that gcc 5.x and 6.x should stay in oe-core for
>>> this cycle, and then drop 5.x after the release.
>>
>>
>> Wouldn't that be dropped iff GCC 7.0 is release? or are you saying we
>> should only have one GCC version?
>>
> 
> Well, depends on the adoption and migration problems.  I don't think we
> should carry three versions,

I agree. 3 is too many.

 and ideally one, but two is acceptable to ease
> migration.

One makes Stable maintenance less costly in time.

- armin
> 


> Ross
> 

Re: Future of GCC

[Richard Purdie]

On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
> 
> On 07/12/2016 02:24 PM, Burton, Ross wrote:
> > On 12 July 2016 at 22:14, akuster808 <akuster808@gmail.com> wrote:
> > 
> > > > Personally I was thinking that gcc 5.x and 6.x should stay in
> > > > oe-core for
> > > > this cycle, and then drop 5.x after the release.
> > > 
> > > 
> > > Wouldn't that be dropped iff GCC 7.0 is release? or are you
> > > saying we
> > > should only have one GCC version?
> > > 
> > 
> > Well, depends on the adoption and migration problems.  I don't
> > think we
> > should carry three versions,
> 
> I agree. 3 is too many.
> 
>  and ideally one, but two is acceptable to ease
> > migration.
> 
> One makes Stable maintenance less costly in time.

I'm personally a fan of one if we can do it. We've taken a bit of an
"easier" path recently but it might be time to change that. Right now
I'm not aware of any of our core usecases which need 5.x, all work with
6.x. I am aware of some BSPs on older kernels which would however have
issues.

I did nearly send a 5.x removal patch but wasn't sure it would be
accepted by people quite yet...

Cheers,

Richard

Re: Future of GCC

[Khem Raj]

On Tue, Jul 12, 2016 at 3:27 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
>>
>> On 07/12/2016 02:24 PM, Burton, Ross wrote:
>> > On 12 July 2016 at 22:14, akuster808 <akuster808@gmail.com> wrote:
>> >
>> > > > Personally I was thinking that gcc 5.x and 6.x should stay in
>> > > > oe-core for
>> > > > this cycle, and then drop 5.x after the release.
>> > >
>> > >
>> > > Wouldn't that be dropped iff GCC 7.0 is release? or are you
>> > > saying we
>> > > should only have one GCC version?
>> > >
>> >
>> > Well, depends on the adoption and migration problems.  I don't
>> > think we
>> > should carry three versions,
>>
>> I agree. 3 is too many.
>>
>>  and ideally one, but two is acceptable to ease
>> > migration.
>>
>> One makes Stable maintenance less costly in time.
>

When we upgrade gcc and it becomes default then most of the validation
and testing for that release happens with that version of gcc. Yes we have
been carrying the older version of gcc however it goes our largely untested
in the new release. We even dont know if the new recipes we upgrade in
the given release have any issues or build with this version of gcc. Everyone
should just default to the default gcc that comes with the release.  So if you
have been on 2.0 release and your apps building with gcc5, upgrading to yocto
2.2 where gcc6 becomes default may not guarantee you well tested metadata
for gcc5. So its in your interest to start using gcc6 with 2.2, and if
one still needs
to keep using gcc5, its not a big deal for them to carry the compiler recipes
in their own layer.


> I'm personally a fan of one if we can do it. We've taken a bit of an
> "easier" path recently but it might be time to change that. Right now
> I'm not aware of any of our core usecases which need 5.x, all work with
> 6.x. I am aware of some BSPs on older kernels which would however have
> issues.
>
> I did nearly send a 5.x removal patch but wasn't sure it would be
> accepted by people quite yet...

You should send it. This will help us concentrate on improving the quality
of default compiler.

>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Future of GCC

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1934 bytes --]

On Tue, Jul 12, 2016 at 11:27:15PM +0100, Richard Purdie wrote:
> On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
> > 
> > On 07/12/2016 02:24 PM, Burton, Ross wrote:
> > > On 12 July 2016 at 22:14, akuster808 <akuster808@gmail.com> wrote:
> > > 
> > > > > Personally I was thinking that gcc 5.x and 6.x should stay in
> > > > > oe-core for
> > > > > this cycle, and then drop 5.x after the release.
> > > > 
> > > > 
> > > > Wouldn't that be dropped iff GCC 7.0 is release? or are you
> > > > saying we
> > > > should only have one GCC version?
> > > > 
> > > 
> > > Well, depends on the adoption and migration problems.  I don't
> > > think we
> > > should carry three versions,
> > 
> > I agree. 3 is too many.
> > 
> >  and ideally one, but two is acceptable to ease
> > > migration.
> > 
> > One makes Stable maintenance less costly in time.
> 
> I'm personally a fan of one if we can do it. We've taken a bit of an
> "easier" path recently but it might be time to change that. Right now
> I'm not aware of any of our core usecases which need 5.x, all work with
> 6.x. I am aware of some BSPs on older kernels which would however have
> issues.

There are many PNBLACKLIST in other layers in recipes which don't even
build with gcc-6 and other which possibly have more issues in runtime.

But I agree that it's easier to officially support just one default gcc
and I'm in favour of removing 5.x from oe-core.

We also used to have gcc 4.3 in meta-openembedded/toolchain-layer which
was removed in:

commit 5a5ec1c0607466d0369170c7a3e25ca92d51ca1c
Author: mike.looijmans@topic.nl <mike.looijmans@topic.nl>
Date:   Thu Oct 8 07:39:20 2015 +0200

    Remove toolchain-layer

If there is enough interest to share the 5.x recipes somewhere, then
people actually using/testing it should do that and I would accept
meta-openembedded patch reviving toolchain-layer with 5.x in it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]