On Tue, Jul 12, 2016 at 3:27 PM, Richard Purdie <richard.pur...@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 <akuster...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
