F22 System Wide Change: GCC5

Peter Robinson pbrobinson at gmail.com
Wed Jan 14 15:05:09 UTC 2015


>> > > http://gcc.gnu.org/gcc-5/porting_to.html → 404
>> >
>> > That will be added likely after the test mass rebuild with what we find
>> > during that.
>>
>> Do you have any estimate when it will be done? F22 schedule is/will be pretty
>> tight. We already have problem scheduling mass rebuild and I expect GCC 5
>> would require as long as possible period to fix issues/build problems. This
>
> How is that different from any other past Fedora releases (with the
> exception of F21)?  If I remember well, at least starting with GCC 4.3 (March 2008)
> new GCC was deployed always in the spring release of Fedora, we've skipped
> 4.2 before that and as there was no spring release last year, GCC 4.9 was
> kind of an exception too.
>
>> time, schedule is more strict time based - what would it mean for you if
>> GCC 5 will miss F22? I'm not saying it's going to happen but it could be
>> option.
>
> Well, if we want to turn Fedora into a collection of obsolete software
> rather than trying to lead progress, we don't have to update anything.

I think that's a bit of an over reaction, ultimately F-22 is due to
branch on February 10th which is less than a month from now, the
moment it branches gcc5 could land and people are then free to rebuild
anything they like and gcc5 will be in the October release which is in
all likely hood earlier than most other distros would adopt it anyway.

> In the past, from my experience with both GCC distro maintainer and upstream
> maintainer hats, shipping GCC early in Fedora helped both projects,
> the early deployment in Fedora helped Fedora developers to use latest
> langauge features (e.g. GCC 5 will finally have C++11 compliant std::string

And how is that any different if it lands in f-23/rawhide in mid Feb?

> or std::list, and feature completeness on the C++14 language side, see
> changes.html for other stuff), help upstreams make the packages more
> portable and enjoy better generated code (e.g. if you really want to make
> PIE the default on x86_64, doing it with 4.9 is just a terribly bad idea
> because only in 5 you can actually rely on PIE copy relocs and not get hit
> as much by the PIE penalty as before), and for the GCC project lead to
> wider testing and more bugfixes.

So the feature gets delayed by a release and it gets enabled in F-23


More information about the devel mailing list