Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, May 13, 2019 at 10:44:45PM +0200, Dridi Boukelmoune wrote: > On Mon, May 13, 2019 at 7:57 PM Jakub Jelinek wrote: > > > > Sorry for digging up this thread, but since this is a recurring change > > > it appears that the mass rebuild is not enough by itself. As of today > > > lcov doesn't work with GCC 9.x [1] and it would be nice if either: > > > > > > - gcc provided an option to use a previous gcov format when a new one > > > lands (I understand it makes things more complicated) > > > > No, we certainly don't want to diverge from gcc upstream here, and gcc > > upstream doesn't have that. > > My idea was rather to bring the suggestion upstream if it is relevant :) > > > > - the Fedora lcov spec would run `make test` in a %check section That won't actually fix the problem - it'd just mean that lcov FTBFS and likely get thrown out of Fedora entirely. > > lcov maintainers have been told they should use the json intermediate format > > from gcov -i instead of trying to parse the binary data. > > Well, not everyone runs Fedora so lcov will still have to support the > binary format for platforms that don't adopt new GCC versions as fast. This has been reported to upstream lcov community every time they break on new GCC releases & I've backported fixes to Fedora once they are available. Most recently I reported the incompatibility with gcc9 way back in January this year https://github.com/linux-test-project/lcov/issues/58 I can't do anything to fix lcov in Fedora until upstream provides the fixes. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, May 13, 2019 at 7:57 PM Jakub Jelinek wrote: > > Sorry for digging up this thread, but since this is a recurring change > > it appears that the mass rebuild is not enough by itself. As of today > > lcov doesn't work with GCC 9.x [1] and it would be nice if either: > > > > - gcc provided an option to use a previous gcov format when a new one > > lands (I understand it makes things more complicated) > > No, we certainly don't want to diverge from gcc upstream here, and gcc > upstream doesn't have that. My idea was rather to bring the suggestion upstream if it is relevant :) > > - the Fedora lcov spec would run `make test` in a %check section > > lcov maintainers have been told they should use the json intermediate format > from gcov -i instead of trying to parse the binary data. Well, not everyone runs Fedora so lcov will still have to support the binary format for platforms that don't adopt new GCC versions as fast. I hope json support was what they were hoping to get done before May from the github issue I linked. But as a gcc+gcov+lcov user, that also requires me as an end-user to actively run gcov and lcov with the right set of flags once lcov support is here. That also means that if I have automation in place that expects to work with either GCC or LLVM toolchains, it makes things more complicated if I need my build system to work not only for me on Fedora 30 but for other team members working on the same project but on different operating systems. Hence my comment regarding compatibility when the binary format changes. Again, if that is relevant. I personally work with both toolchains, because each major release usually brings new helpful warnings or diagnostics. And for that matter I'm really happy to be on Fedora and act as a canary to learn what's coming. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, May 13, 2019 at 07:42:16PM +0200, Dridi Boukelmoune wrote: > On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek wrote: > > > > On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote: > > > This is already happening, gcc was updated, I see bugs for gcc 9 related > > > FTBFS being open. This is not a proper way to coordinate this kind of > > > thing. > > > > I'm sorry, I forgot to create the every year feature request for GCC this > > year and only realized that when I've successfully built first non-scratch > > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > > has been discussed and GCC updates is something that has been done every > > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > > in 2007). > > > > That said, a test mass rebuild has been performed (this year by Jeff Law) > > and issues have been analyzed. > > Sorry for digging up this thread, but since this is a recurring change > it appears that the mass rebuild is not enough by itself. As of today > lcov doesn't work with GCC 9.x [1] and it would be nice if either: > > - gcc provided an option to use a previous gcov format when a new one > lands (I understand it makes things more complicated) No, we certainly don't want to diverge from gcc upstream here, and gcc upstream doesn't have that. > - the Fedora lcov spec would run `make test` in a %check section lcov maintainers have been told they should use the json intermediate format from gcov -i instead of trying to parse the binary data. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek wrote: > > On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote: > > This is already happening, gcc was updated, I see bugs for gcc 9 related > > FTBFS being open. This is not a proper way to coordinate this kind of thing. > > I'm sorry, I forgot to create the every year feature request for GCC this > year and only realized that when I've successfully built first non-scratch > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > has been discussed and GCC updates is something that has been done every > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > in 2007). > > That said, a test mass rebuild has been performed (this year by Jeff Law) > and issues have been analyzed. Sorry for digging up this thread, but since this is a recurring change it appears that the mass rebuild is not enough by itself. As of today lcov doesn't work with GCC 9.x [1] and it would be nice if either: - gcc provided an option to use a previous gcov format when a new one lands (I understand it makes things more complicated) - the Fedora lcov spec would run `make test` in a %check section Ideally both for the sake of continuity/easier transitions. At the very least we would learn with the latter at mass rebuild time that such a problem exists. TIL that lcov is a noarch package, I had no idea! And fortunately clang and llvm-cov are still using the old format so for now I can still build code coverage reports but it's a bit annoying to discover this after upgrading. Dridi [1] https://github.com/linux-test-project/lcov/issues/58 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 01:22:19PM +, Daniel P. Berrangé wrote:
> On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
> > On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> > > The variable was already initialized right at the start. The compound
> > > literal is just a short-hand for later changing the values in several
> > > fields of the struct at once. This is no different to manually assigning
> > > new values to each individual field one at a time. eg
> > >
> > > struct demo demo = {0};
> > >
> > > ...some code with a goto...
> > >
> > > demo = (struct demo) { .cmd = "foo" };
> >
> > No, I wasn't talking about the demo variable, the warning is not about demo
> > variable. The warning is about the compound literal variable.
> > That is an anonymous (when used at block scope automatic) variable, kind
> > like:
> > struct demo __complit = { .cmd = "foo" };
> > demo = __complit;
> > and with the goto you are crossing initialization of that variable.
>
> Urgh. I would never have understood that from the warning message :-( It
> is complaining about something that doesn't even exist as far as I was
> concerned
>
> > When you aren't taking address of this, the optimizers will likely optimize
> > the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
> > that address could be used later on in the function, dereferenced etc.
>
> Is it practical to get the warning supressed when code is not taking the
> address of the anonymous var ?
>
> If not then we pretty much have to abandon use of these anonymous
> compound initializers for re-assigning existing variables :-(
Let me second that. In systemd upstream we have been slowly changing
code to use compound initializers instead in places where "all" fields
of a structure would be assigned. With explicit list it's easy to miss
some fields when the code is changed, and compound initialization
avoids this risk. It's much more elegant.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 02:12:03PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> > The variable was already initialized right at the start. The compound
> > literal is just a short-hand for later changing the values in several
> > fields of the struct at once. This is no different to manually assigning
> > new values to each individual field one at a time. eg
> >
> > struct demo demo = {0};
> >
> > ...some code with a goto...
> >
> > demo = (struct demo) { .cmd = "foo" };
>
> No, I wasn't talking about the demo variable, the warning is not about demo
> variable. The warning is about the compound literal variable.
> That is an anonymous (when used at block scope automatic) variable, kind
> like:
> struct demo __complit = { .cmd = "foo" };
> demo = __complit;
> and with the goto you are crossing initialization of that variable.
Urgh. I would never have understood that from the warning message :-( It
is complaining about something that doesn't even exist as far as I was
concerned
> When you aren't taking address of this, the optimizers will likely optimize
> the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
> that address could be used later on in the function, dereferenced etc.
Is it practical to get the warning supressed when code is not taking the
address of the anonymous var ?
If not then we pretty much have to abandon use of these anonymous
compound initializers for re-assigning existing variables :-(
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
* Jakub Jelinek:
> On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
>> Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
>> warnings for code using anonymous struct initializers during assignments:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
>> https://bugzilla.redhat.com/show_bug.cgi?id=1669489
>>
>> It is quite an ununfortunate bug as it is not straightforward to workaround
>> the bogus warning by changing code, while we also don't want to disable
>> -Wjump-misses-init since it is a useful/important warning in general.
>> So we'd really like to see the regression fixed before F30 GA.
>
> That is not a false positive, you are crossing initialization of the
> compound literal. Older GCC versions mistakenly haven't put the automatic
> variables for the compound literals into the right scope.
> Yes, in your case you are not accessing the compound literal in the cleanup:
> code, but that is exactly the same case when you get a warning for:
> if (whatever)
> goto cleanup;
>
> int i = 26;
>
> cleanup:
> return 0;
I think it's more like getting a warning for this:
int i = 5;
if (whatever)
goto cleanup;
i = 26;
// …
cleanup:
return 0;
In fact, this results in warning, too:
i = (struct { int value; }) { 26 }.value;
As Joseph pointed out on the upstream PR, the warning refers to the
internal variable used to store the compound literal, which the
programmer did not spell out explicitly.
I'm not sure if it is possible that the skipped initialization leads to
undefined behavior, without also involving a pointer to an object that
goes out of scope.
Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> The variable was already initialized right at the start. The compound
> literal is just a short-hand for later changing the values in several
> fields of the struct at once. This is no different to manually assigning
> new values to each individual field one at a time. eg
>
> struct demo demo = {0};
>
> ...some code with a goto...
>
> demo = (struct demo) { .cmd = "foo" };
No, I wasn't talking about the demo variable, the warning is not about demo
variable. The warning is about the compound literal variable.
That is an anonymous (when used at block scope automatic) variable, kind
like:
struct demo __complit = { .cmd = "foo" };
demo = __complit;
and with the goto you are crossing initialization of that variable.
When you aren't taking address of this, the optimizers will likely optimize
the temporary away later on, if you'd do &(struct demo) { .cmd = "foo" }
that address could be used later on in the function, dereferenced etc.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 01:56:19PM +0100, Jakub Jelinek wrote:
> On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
> > Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
> > warnings for code using anonymous struct initializers during assignments:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
> > https://bugzilla.redhat.com/show_bug.cgi?id=1669489
> >
> > It is quite an ununfortunate bug as it is not straightforward to workaround
> > the bogus warning by changing code, while we also don't want to disable
> > -Wjump-misses-init since it is a useful/important warning in general.
> > So we'd really like to see the regression fixed before F30 GA.
>
> That is not a false positive, you are crossing initialization of the
> compound literal. Older GCC versions mistakenly haven't put the automatic
> variables for the compound literals into the right scope.
The variable was already initialized right at the start. The compound
literal is just a short-hand for later changing the values in several
fields of the struct at once. This is no different to manually assigning
new values to each individual field one at a time. eg
struct demo demo = {0};
...some code with a goto...
demo = (struct demo) { .cmd = "foo" };
is no different from
struct demo demo = {0};
...some code with a goto...
demo.cmd = "foo"
and neither should generate warnings about missing initializers with gotos.
> Yes, in your case you are not accessing the compound literal in the cleanup:
> code, but that is exactly the same case when you get a warning for:
Even if we were accessing the the variable in the cleanup code, it would
not be a missing initializer, as the variable was initialized at the time
it was declared before any goto.
> if (whatever)
> goto cleanup;
>
> int i = 26;
>
> cleanup:
> return 0;
This is a completely different scenario, as it is jumping over the
declaration of the variable and its only initializer.
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote: > Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus > warnings for code using anonymous struct initializers during assignments: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 > https://bugzilla.redhat.com/show_bug.cgi?id=1669489 > > It is quite an ununfortunate bug as it is not straightforward to workaround > the bogus warning by changing code, while we also don't want to disable > -Wjump-misses-init since it is a useful/important warning in general. > So we'd really like to see the regression fixed before F30 GA. That is not a false positive, you are crossing initialization of the compound literal. Older GCC versions mistakenly haven't put the automatic variables for the compound literals into the right scope. Yes, in your case you are not accessing the compound literal in the cleanup: code, but that is exactly the same case when you get a warning for: if (whatever) goto cleanup; int i = 26; cleanup: return 0; Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 03:16:56PM -0500, Ben Cotton wrote: > [This proposal was submitted after the deadline. I am announcing it > for community discussion and will leave the decision on whether or not > to grant an exception to FESCo] > > https://fedoraproject.org/wiki/Changes/GCC9 > > == Summary == > Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 31. > > == Owner == > * Name: [[User:jakub| Jakub Jelínek]] > * Email: ja...@redhat.com > > > == Detailed Description == > GCC 9 is currently in stage4 since January 7th, in prerelease state > with only regression bugfixes and documentation fixes allowed. The > release will happen probably in the middle of April. > rpms have been built are since today in rawhide. > == User Experience == > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, > or, if they detect a GCC bug, report it. Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus warnings for code using anonymous struct initializers during assignments: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 https://bugzilla.redhat.com/show_bug.cgi?id=1669489 It is quite an ununfortunate bug as it is not straightforward to workaround the bogus warning by changing code, while we also don't want to disable -Wjump-misses-init since it is a useful/important warning in general. So we'd really like to see the regression fixed before F30 GA. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 29, 2019 at 07:07:02AM -0500, Siteshwar Vashisht wrote:
>
>
> - Original Message -
> > From: "Jakub Jelinek"
> > To: "Development discussions related to Fedora"
> >
> > Sent: Monday, January 21, 2019 10:51:32 PM
> > Subject: Re: [Late] F30 System-Wide Change proposal: GCC9
> >
> > The release notes are WIP, more will come when it is written, many new
> > features
> > are just not described there yet.
>
> One of my packages broke because gcc now prints line numbers with error
> messages. Just in case anyone else is facing similar issue.
'-fno-diagnostics-show-caret'
By default, each diagnostic emitted includes the original source
line and a caret '^' indicating the column. This option suppresses
this information. The source line is truncated to N characters, if
the '-fmessage-length=n' option is given. When the output is done
to the terminal, the width is limited to the width given by the
'COLUMNS' environment variable or, if not set, to the terminal
width.
'-fno-diagnostics-show-labels'
By default, when printing source code (via
'-fdiagnostics-show-caret'), diagnostics can label ranges of source
code with pertinent information, such as the types of expressions:
printf ("foo %s bar", long_i + long_j);
~^ ~~~
| |
char * long int
This option suppresses the printing of these labels (in the example
above, the vertical bars and the "char *" and "long int" text).
'-fno-diagnostics-show-line-numbers'
By default, when printing source code (via
'-fdiagnostics-show-caret'), a left margin is printed, showing line
numbers. This option suppresses this left margin.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
- Original Message - > From: "Jakub Jelinek" > To: "Development discussions related to Fedora" > > Sent: Monday, January 21, 2019 10:51:32 PM > Subject: Re: [Late] F30 System-Wide Change proposal: GCC9 > > The release notes are WIP, more will come when it is written, many new > features > are just not described there yet. One of my packages broke because gcc now prints line numbers with error messages. Just in case anyone else is facing similar issue. > > Jakub > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- -- Siteshwar Vashisht ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, 21 Jan 2019 at 21:27, Ben Cotton wrote: [..] > == User Experience == > Users will be able to see compiled code improvements and use the newly > added features. > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, > or, if they detect a GCC bug, report it. > FTR only. Just tested gcc 9.0.0 on one of my projects and seems like gcc 9 is producilng slightly bigger code compare to gcc 8.2.1. https://github.com/kloczek/tvision/commit/4cf6f4e3f647f67eac886c5a4264e8b63183445e kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
Thank you two for the answer. YOUNG, MICHAEL A. wrote on Sat, Jan 26, 2019 at 12:53:18PM +: > The problem is your gcc build requires libgcc_s.so.1 which is the i386 > version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has > gone wrong in your build process. Eh, even after reading this I was doubting you, but that appears to be true... I guess asking rpm to add a couple of parenthesis after 32bit lib requires to at least look like 64bit libs require and not a simple file require would be asking too much, I never noticed it worked like this for 32bit libs :/ And rightly enough rpm -qp --requires of "my" gcc does have both libgcc_s.so.1 while fc30's libgcc.x86_64 only requires the x86_64 version; interesting given the src.rpm is the same. I've extracted the rpm and am not quite sure where the auto requires comes from, actually? I thought there was a script doing basically ldd on each executable (as described on the rpm website[1]), but nothing in the gcc package seems to require libgcc_s - what am I missing? I can't see anything obviously different between both build logs, either copr's[2] or koji's[3] (caution: files are 10MB (compressed) and 55MB respectively); the logs are too different to diff because of parallel build but at least lines containing "libgcc_s" are similar enough... [1] http://ftp.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html [2] https://copr-be.cloud.fedoraproject.org/results/martinetd/gcc9/fedora-29-x86_64/00850190-gcc/build.log.gz [3] https://kojipkgs.fedoraproject.org//packages/gcc/9.0.1/0.1.fc30/data/logs/x86_64/build.log Will look into how autodepends works a bit more, I'm curious why this is different. Thanks, -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Sat, 26 Jan 2019, Dominique Martinet wrote: > Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +: >>> I think it would help having more people test things, and if there are >>> build failures would help package owners fix these - it's not always >>> obvious to fix a build failure by repeatedly submitting a new package to >>> build, and everyone doesn't have a rawhide install around. >> >> That's what 'mock' is for. > > Sure, I guess that was a bad argument; as I said I'm not maintaining > packages so I can't do that for the tools where I'd have liked to test > the new gcc. > >>> It's probably just me being lazy, though; I'll figure something out if >>> there is no such plan :) >> >> It's really easy to build it yourself: >> https://gcc.gnu.org/wiki/InstallingGCC >> >> Installing binutils is also simple. Build binutils and install it >> first, then build GCC to use the same prefix as you installed binutils >> to, and the new GCC will automatically use the new GCC. > > Sure, building a new toolchain is easy; that's one of the many > possibilities there are to test it. > One could also just use `dnf --installroot=/tmp/foo --releasever=30 > isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of > these solutions take disk space and aren't systematically used when > building stuff so it makes the testing a much more conscious action than > just install some rpm and start using it. > (yes, if I build a toolchain I could just add it to my PATH and it would > just work as well; as I said, I'm just lazy.) > > > Honestly, I also figured dropping the existing fc30 srpm for gcc > followed by libtools and friends in a fc29 copr would be even simpler > for everyone - copr really is a great tool to test new utility versions, > and most of the time it just works. > > Turns out I wasn't correct here as for some reason gcc9 does build fine > but I can't get it to install in a chroot, feel free to try my attempt > if you can figure why: > https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ > > I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but > trying to install gcc itself yields: > Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none > of the providers can be installed > - libgcc-8.2.1-6.fc29.i686 has inferior architecture > - libgcc-8.2.1-2.fc29.i686 has inferior architecture > - cannot install both libgcc-8.2.1-6.fc29.x86_64 and > libgcc-9.0.1-0.1.fc29.x86_64 > - cannot install both libgcc-8.2.1-2.fc29.x86_64 and > libgcc-9.0.1-0.1.fc29.x86_64 > - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but > none of the providers can be installed > - cannot install the best candidate for the job > > while it really looks to me that it should be provided by the newer > libgcc? > # rpm -q --provides libgcc > libgcc = 9.0.1-0.1.fc29 > libgcc(x86-64) = 9.0.1-0.1.fc29 > libgcc_s.so.1()(64bit) > libgcc_s.so.1(GCC_3.0)(64bit) > libgcc_s.so.1(GCC_3.3)(64bit) > libgcc_s.so.1(GCC_3.3.1)(64bit) > libgcc_s.so.1(GCC_3.4)(64bit) > libgcc_s.so.1(GCC_3.4.2)(64bit) > libgcc_s.so.1(GCC_3.4.4)(64bit) > libgcc_s.so.1(GCC_4.0.0)(64bit) > libgcc_s.so.1(GCC_4.2.0)(64bit) > libgcc_s.so.1(GCC_4.3.0)(64bit) > libgcc_s.so.1(GCC_4.7.0)(64bit) > libgcc_s.so.1(GCC_4.8.0)(64bit) > libgcc_s.so.1(GCC_7.0.0)(64bit) > > So, meh, I'll probably pick something else but I don't like not > understanding why something doesn't work. The problem is your gcc build requires libgcc_s.so.1 which is the i386 version; the x86_64 version is libgcc_s.so.1()(64bit) . So something has gone wrong in your build process. Michael Young ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
Jonathan Wakely wrote on Fri, Jan 25, 2019 at 05:06:09PM +: >> I think it would help having more people test things, and if there are >> build failures would help package owners fix these - it's not always >> obvious to fix a build failure by repeatedly submitting a new package to >> build, and everyone doesn't have a rawhide install around. > > That's what 'mock' is for. Sure, I guess that was a bad argument; as I said I'm not maintaining packages so I can't do that for the tools where I'd have liked to test the new gcc. > >It's probably just me being lazy, though; I'll figure something out if > >there is no such plan :) > > It's really easy to build it yourself: > https://gcc.gnu.org/wiki/InstallingGCC > > Installing binutils is also simple. Build binutils and install it > first, then build GCC to use the same prefix as you installed binutils > to, and the new GCC will automatically use the new GCC. Sure, building a new toolchain is easy; that's one of the many possibilities there are to test it. One could also just use `dnf --installroot=/tmp/foo --releasever=30 isntall gcc` to pop a new chroot, or install rawhide in a VM, but all of these solutions take disk space and aren't systematically used when building stuff so it makes the testing a much more conscious action than just install some rpm and start using it. (yes, if I build a toolchain I could just add it to my PATH and it would just work as well; as I said, I'm just lazy.) Honestly, I also figured dropping the existing fc30 srpm for gcc followed by libtools and friends in a fc29 copr would be even simpler for everyone - copr really is a great tool to test new utility versions, and most of the time it just works. Turns out I wasn't correct here as for some reason gcc9 does build fine but I can't get it to install in a chroot, feel free to try my attempt if you can figure why: https://copr.fedorainfracloud.org/coprs/martinetd/gcc9/ I could upgrade libgcc/libgomp/libstdc++ (in a chroot without gcc) but trying to install gcc itself yields: Problem: package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc_s.so.1, but none of the providers can be installed - libgcc-8.2.1-6.fc29.i686 has inferior architecture - libgcc-8.2.1-2.fc29.i686 has inferior architecture - cannot install both libgcc-8.2.1-6.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - cannot install both libgcc-8.2.1-2.fc29.x86_64 and libgcc-9.0.1-0.1.fc29.x86_64 - package gcc-9.0.1-0.1.fc29.x86_64 requires libgcc >= 9.0.1-0.1.fc29, but none of the providers can be installed - cannot install the best candidate for the job while it really looks to me that it should be provided by the newer libgcc? # rpm -q --provides libgcc libgcc = 9.0.1-0.1.fc29 libgcc(x86-64) = 9.0.1-0.1.fc29 libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_3.4)(64bit) libgcc_s.so.1(GCC_3.4.2)(64bit) libgcc_s.so.1(GCC_3.4.4)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgcc_s.so.1(GCC_4.2.0)(64bit) libgcc_s.so.1(GCC_4.3.0)(64bit) libgcc_s.so.1(GCC_4.7.0)(64bit) libgcc_s.so.1(GCC_4.8.0)(64bit) libgcc_s.so.1(GCC_7.0.0)(64bit) So, meh, I'll probably pick something else but I don't like not understanding why something doesn't work. -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On 22/01/19 08:52 +0100, Dominique Martinet wrote: Hi, Ben Cotton wrote on Mon, Jan 21, 2019 at 03:16:56PM -0500: == Detailed Description == GCC 9 is currently in stage4 since January 7th, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms have been built are since today in rawhide. (writing "today" in a change page that stays on a wiki can be confusing if it gets updated later on) * Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report. I don't have packages to rebuild (evil lurker here), but love to test on some programs I contribute to. Is there any plan to have a copr with gcc+libtools for fedora 29 or would that be too much extra work at this point? I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around. That's what 'mock' is for. It's probably just me being lazy, though; I'll figure something out if there is no such plan :) It's really easy to build it yourself: https://gcc.gnu.org/wiki/InstallingGCC Installing binutils is also simple. Build binutils and install it first, then build GCC to use the same prefix as you installed binutils to, and the new GCC will automatically use the new GCC. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 22, 2019 at 3:35 PM Martin Kolman wrote: > > On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote: > > On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: > > > I'm sorry, I forgot to create the every year feature request for GCC this > > > year and only realized that when I've successfully built first non-scratch > > > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass > > > rebuild > > > has been discussed and GCC updates is something that has been done every > > > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > > > in 2007). > > > > That's all true, but the change process still helps us coordinate. There are > > many new people in Fedora every year, and the more we have documented and > > explicit rather than "oh yeah, this happens every year", the better. > It also be of historical importance later on - it documents why and when the > change was done > for future generations, who might no longer remember the reasoning. > > There might be even cases where you find software referencing some strange > other project, > only to find two old Fedora change pages, one documenting the project being > added to Fedora and > another one documenting it being replaced by something else later on. I don't think the Change process actually helps that. If anything, some of the Change pages just contribute to that. > This can be really helpful when hunting down obscure bugs or untangling > reasons for past design decisions. I mean this in the most constructive way, but the Change process is not a design/architecture process. It is a collection of things that individual teams want to do that impacts the rest of the distro, which get approved if nobody objects (or notices too late). A design decision implies an overall architecture to the distribution that is not really present in Fedora. > > It sounds like you're thinking of it a little as "bureaucratic paperwork > > where we pretend that there's some debate about whether we're going to > > continue doing a completely normal thing". But it's not that. It's "the > > process for making sure our routine update to GCC across the whole distro > > goes smoothly for everyone". Perhaps I have a tinted view at this point, but I think Fedora has to outgrown the Change process. At the very least, turn it into something that is far less rubber-stampy and more coordinated and planned. Things like the yearly GCC rebase should be fundamental requirements that drive other actions, not something that has to be remembered to be filed in on a wiki every year as if we suddenly would stop doing that if the page didn't get created one time. E.g. we know we'll update GCC in a similar window of time year to year, so if we know that then perhaps we can use it to start articulating what a Fedora Platform really means. Perhaps we use that to drive a lifecycle for a particular ring/platform/whatever that other applications can build and rely on. I happened to sit in on two talks today that had pieces that resonated with me around affecting change, and how we tell ourselves we work in some particular way but in reality we are doing something else. We keep circling around a lot of things in Fedora that we want to investigate or change or improve, but then we continue to do the same things day in and day out. Perhaps instead of looking for completely new ways to do things, we can look at what we *really* do and not what we tell ourselves we do, and correct or build from those things towards what we want. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, 2019-01-22 at 08:21 -0500, Matthew Miller wrote: > On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: > > I'm sorry, I forgot to create the every year feature request for GCC this > > year and only realized that when I've successfully built first non-scratch > > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > > has been discussed and GCC updates is something that has been done every > > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > > in 2007). > > That's all true, but the change process still helps us coordinate. There are > many new people in Fedora every year, and the more we have documented and > explicit rather than "oh yeah, this happens every year", the better. It also be of historical importance later on - it documents why and when the change was done for future generations, who might no longer remember the reasoning. There might be even cases where you find software referencing some strange other project, only to find two old Fedora change pages, one documenting the project being added to Fedora and another one documenting it being replaced by something else later on. This can be really helpful when hunting down obscure bugs or untangling reasons for past design decisions. > > It sounds like you're thinking of it a little as "bureaucratic paperwork > where we pretend that there's some debate about whether we're going to > continue doing a completely normal thing". But it's not that. It's "the > process for making sure our routine update to GCC across the whole distro > goes smoothly for everyone". > > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On ti, 22 tammi 2019, Matthew Miller wrote: On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007). That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better. It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone". To add to what Matthew said, I'll show another example: https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules was passed in Fedora 29 without real communication with actual complex users of nss databases in Fedora (FreeIPA, Dogtag) even though we are working in a common understanding that something like that was needed. As result, it broke use of SoftHSM in FreeIPA and Dogtag and continues to be a blocker for our effort to add support of hardware-based security modules in FreeIPA. We have to deal with the fact that now a lot of work have to be directed into workarounding what looked as a nice logical global change in Fedora. Needless to say, neither FreeIPA nor Dogtag were mentioned in the change and weren't consulted. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 22, 2019 at 10:29:28AM +0100, Jakub Jelinek wrote: > I'm sorry, I forgot to create the every year feature request for GCC this > year and only realized that when I've successfully built first non-scratch > gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild > has been discussed and GCC updates is something that has been done every > year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back > in 2007). That's all true, but the change process still helps us coordinate. There are many new people in Fedora every year, and the more we have documented and explicit rather than "oh yeah, this happens every year", the better. It sounds like you're thinking of it a little as "bureaucratic paperwork where we pretend that there's some debate about whether we're going to continue doing a completely normal thing". But it's not that. It's "the process for making sure our routine update to GCC across the whole distro goes smoothly for everyone". -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On 22. 01. 19 10:29, Jakub Jelinek wrote: On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote: This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing. I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007). That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
Am Montag, den 21.01.2019, 15:16 -0500 schrieb Ben Cotton: > * Proposal owners: > Build gcc in f30, rebuild packages that have direct dependencies on > exact gcc version (libtool, annobin, gcc-python-plugin). Did not happen. Rawhide buildroot was broken yesterday around 9:50 UTC. I was doing the rebuilds about one hour *after* GCC-9 was build, just to have a working buildroot on Koji again [1]. gcc-python-plugin wasn't rebuilt until I triggered the build this morning and the package actually is FTBFS due to GCC-9 [2]. This should have been done in a proper chain-build. If the change owner does not have the needed powers for rebuilding other packages, help and coordination from a provenpackager should have been requested *prior* to just dropping in a new major version of GCC. Anyways, the intention to build a new major version of GCC should have been announced at least one week *before* silently dropping it into Rawhide. > == Contingency Plan == > If bugs are discovered, I'd appreciate help from the package owners in > preparing self-contained testcases to speed up analysis and fixing the > bugs. Don't have time to debug issues in > 12000+ packages, especially when in many cases it could be caused by > undefined code in the packages etc. I don't expect we'll have to fall > back to the older gcc, we've never had to do it in the past, > but worst case we can mass rebuild everything with older gcc again. > Jeff Law has performed test mass rebuild on x86_64. Where are the results of that test mass-rebuild to be found? How much is the fallout in these rebuilds? At least one of my critpath packages (libxcrypt) would have been FTBFS due to GCC-9, if I wouldn't have pushed an immediate fix [3]. [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E5KJUS2VUGKUKODYN7MPFXWBIMR7HZZF/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1668175 [3] https://github.com/besser82/libxcrypt/issues/76 signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote: > This is already happening, gcc was updated, I see bugs for gcc 9 related > FTBFS being open. This is not a proper way to coordinate this kind of thing. I'm sorry, I forgot to create the every year feature request for GCC this year and only realized that when I've successfully built first non-scratch gcc 9 rpms. I believe Carlos has been mentioning GCC when F30 mass rebuild has been discussed and GCC updates is something that has been done every year in Fedora since at least Fedora 9 (we've skipped GCC 4.2 release back in 2007). That said, a test mass rebuild has been performed (this year by Jeff Law) and issues have been analyzed. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On 21. 01. 19 23:42, Ben Cotton wrote: On Mon, Jan 21, 2019 at 4:38 PM Zbigniew Jędrzejewski-Szmek wrote: I think we want this to go through. The new version is already packaged and I know some work has been done to resolve compilation failures. There's still plenty of time to resolve the remaining issues. I agree, mostly because getting the new GCC in fits well with our "First" foundation (assuming there aren't show-stopper bugs, etc). But... It would also be very awkward to *not* allow this: gcc has already been built in F30, so we'd need to bump the epoch and build a lower version after branching if we want to keep using 8.x in F30. That'd not be pretty. ...this is a bad reason to approve a change, IMO. In order for the Change process to work as intended, Changes should be submitted and approved before being implemented. Exactly. I'd very much vote +1 for a gcc update, but this is not a way to do it. This is already happening, gcc was updated, I see bugs for gcc 9 related FTBFS being open. This is not a proper way to coordinate this kind of thing. The process is roughly: * change proposal * approval * do it Not: * do it * change proposal * what goes here exactly? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
Hi, Ben Cotton wrote on Mon, Jan 21, 2019 at 03:16:56PM -0500: > == Detailed Description == > GCC 9 is currently in stage4 since January 7th, in prerelease state > with only regression bugfixes and documentation fixes allowed. The > release will happen probably in the middle of April. > rpms have been built are since today in rawhide. (writing "today" in a change page that stays on a wiki can be confusing if it gets updated later on) > * Other developers: First few days/weeks just voluntary rebuilds using > the new system gcc, if things fail, look at > http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, > if there is a gcc bug or suspected gcc bug, analyze and report. I don't have packages to rebuild (evil lurker here), but love to test on some programs I contribute to. Is there any plan to have a copr with gcc+libtools for fedora 29 or would that be too much extra work at this point? I think it would help having more people test things, and if there are build failures would help package owners fix these - it's not always obvious to fix a build failure by repeatedly submitting a new package to build, and everyone doesn't have a rawhide install around. It's probably just me being lazy, though; I'll figure something out if there is no such plan :) Thanks, -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 4:38 PM Zbigniew Jędrzejewski-Szmek wrote: > > I think we want this to go through. The new version is already packaged and > I know some work has been done to resolve compilation failures. There's > still plenty of time to resolve the remaining issues. > I agree, mostly because getting the new GCC in fits well with our "First" foundation (assuming there aren't show-stopper bugs, etc). But... > It would also be very awkward to *not* allow this: gcc has already > been built in F30, so we'd need to bump the epoch and build a lower > version after branching if we want to keep using 8.x in F30. That'd > not be pretty. > ...this is a bad reason to approve a change, IMO. In order for the Change process to work as intended, Changes should be submitted and approved before being implemented. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On 21. 01. 19 21:16, Ben Cotton wrote: [This proposal was submitted after the deadline. I am announcing it for community discussion and will leave the decision on whether or not to grant an exception to FESCo] https://fedoraproject.org/wiki/Changes/GCC9 == Summary == Switch GCC in Fedora 30 to 9.x.y... AFAIK this already happened. What do I miss? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 10:36:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote: > I certainly would be very disappointed to not see the latest release > of gcc in Fedora. The release notes are underwhelming, but I expect > there are many improvements to look forward to. For example, I know > there are some new diagnostics (we fixed two minor bugs in systemd > because of them). The release notes are WIP, more will come when it is written, many new features are just not described there yet. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 03:27:23PM -0500, Neal Gompa wrote: > On Mon, Jan 21, 2019 at 3:17 PM Ben Cotton wrote: > > > > [This proposal was submitted after the deadline. I am announcing it > > for community discussion and will leave the decision on whether or not > > to grant an exception to FESCo] I think we want this to go through. The new version is already packaged and I know some work has been done to resolve compilation failures. There's still plenty of time to resolve the remaining issues. It would also be very awkward to *not* allow this: gcc has already been built in F30, so we'd need to bump the epoch and build a lower version after branching if we want to keep using 8.x in F30. That'd not be pretty. > > == Release Notes == > > Fedora 30 comes with GCC 9.1 as primary compiler, see > > http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it. > > I, for one, am excited for GCC 9. Having the GNU D Compiler in Fedora > will make things tons easier for having software written in D be able > to have the same hardening applied to it that we have for C/C++ > programs. I certainly would be very disappointed to not see the latest release of gcc in Fedora. The release notes are underwhelming, but I expect there are many improvements to look forward to. For example, I know there are some new diagnostics (we fixed two minor bugs in systemd because of them). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [Late] F30 System-Wide Change proposal: GCC9
On Mon, Jan 21, 2019 at 3:17 PM Ben Cotton wrote: > > [This proposal was submitted after the deadline. I am announcing it > for community discussion and will leave the decision on whether or not > to grant an exception to FESCo] > > https://fedoraproject.org/wiki/Changes/GCC9 > > == Summary == > Switch GCC in Fedora 30 to 9.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 31. > > == Owner == > * Name: [[User:jakub| Jakub Jelínek]] > * Email: ja...@redhat.com > > > == Detailed Description == > GCC 9 is currently in stage4 since January 7th, in prerelease state > with only regression bugfixes and documentation fixes allowed. The > release will happen probably in the middle of April. > rpms have been built are since today in rawhide. > > == Benefit to Fedora == > See http://gcc.gnu.org/gcc-9/changes.html for the list of changes. > > == Scope == > All packages should be rebuilt with the new gcc once it hits f30, or, > if there is not enough time for that, just all packages built after > the new gcc hits the buildroots. > > * Proposal owners: > Build gcc in f30, rebuild packages that have direct dependencies on > exact gcc version (libtool, annobin, gcc-python-plugin). > * Other developers: First few days/weeks just voluntary rebuilds using > the new system gcc, if things fail, look at > http://gcc.gnu.org/gcc-9/porting_to.html and fix bugs in packages or, > if there is a gcc bug or suspected gcc bug, analyze and report. > * Release engineering: . Mass rebuild requested for F30. > * Policies and guidelines: No policies need to be changed > > == Upgrade/compatibility impact == > No impact > > == How To Test == > GCC has its own testsuite, which is run during the package build, plus > many other packages with automated tests also help to test the new > gcc. > > == User Experience == > Users will be able to see compiled code improvements and use the newly > added features. > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-9/porting_to.html, > or, if they detect a GCC bug, report it. > > == Dependencies == > libtool, annobin, gcc-python-plugin depend on exact gcc version, those > need to be rebuilt. > > == Contingency Plan == > If bugs are discovered, I'd appreciate help from the package owners in > preparing self-contained testcases to speed up analysis and fixing the > bugs. Don't have time to debug issues in > 12000+ packages, especially when in many cases it could be caused by > undefined code in the packages etc. I don't expect we'll have to fall > back to the older gcc, we've never had to do it in the past, > but worst case we can mass rebuild everything with older gcc again. > Jeff Law has performed test mass rebuild on x86_64. > > * Contingency mechanism: Revert to older gcc, mass rebuild everything again > * Contingency deadline: Before release > * Blocks release? Yes > * Blocks product? No > > == Documentation == > http://gcc.gnu.org/gcc-9/ > > == Release Notes == > Fedora 30 comes with GCC 9.1 as primary compiler, see > http://gcc.gnu.org/gcc-9/changes.html for user visible changes in it. > I, for one, am excited for GCC 9. Having the GNU D Compiler in Fedora will make things tons easier for having software written in D be able to have the same hardening applied to it that we have for C/C++ programs. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
