Future of GCC
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
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 9 lines · 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
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
Quoted 6 lines · Ross
Quoted 4 lines · 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?
Quoted 8 lines
Quoted 5 lines
... 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
Quoted 12 lines
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
Quoted 7 lines · On 12 July 2016 at 22:14, akuster808 <[email protected]> wrote:
Quoted 2 lines
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
Quoted 6 lines · Ross
Quoted 4 lines · On 12 July 2016 at 22:14, akuster808 <[email protected]> wrote:
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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
Quoted 1 line
migration.
One makes Stable maintenance less costly in time.
- armin
Quoted 5 lines
Ross
Quoted 18 lines · On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
Quoted 7 lines · Ross
Quoted 5 lines · On 12 July 2016 at 22:14, akuster808 <[email protected]> wrote:
Quoted 3 lines
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.Quoted 8 lines
Quoted 4 lines
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,
Quoted 6 lines
I agree. 3 is too many.
and ideally one, but two is acceptable to ease
Quoted 1 line
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
Quoted 19 lines · Richard Purdie
Quoted 18 lines · On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
Quoted 15 lines · Ross
Quoted 9 lines · On 12 July 2016 at 22:14, akuster808 <[email protected]> wrote:
Quoted 3 lines
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,
Quoted 7 lines
Quoted 6 lines
I agree. 3 is too many.
and ideally one, but two is acceptable to ease
Quoted 1 line
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.
Quoted 8 lines
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.
Quoted 10 lines
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 24 lines · Richard Purdie
Quoted 23 lines · On Tue, 2016-07-12 at 14:34 -0700, akuster808 wrote:
Quoted 7 lines · Ross
Quoted 5 lines · On 12 July 2016 at 22:14, akuster808 <[email protected]> wrote:
Quoted 3 lines
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.Quoted 8 lines
Quoted 4 lines
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
Quoted 1 line
migration.
Quoted 7 lines
Quoted 1 line
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: [email protected] <[email protected]> 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.