Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tue, Jan 21, 2020 at 1:35 PM Miro Hrončok wrote: > > Hello, Hi Miro, > we try to rebuild all Python packages against Python 3.9 and report the > failures. I've seen several similar failures in a row now that can be > reproduced > in Fedora rawhide with the new gcc version. > > ld errors on multiple definitions of ..., for example: I've seen this issue pop up in some other packages, as well. My elementary-files package is affected, and I think it broke rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a lot of ruby packages; though I can't access the build log for the failed rubygem-ffi build, due to a koji bug relating to side tags). Fabio > ld: > tests/bp_account.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_account.c:22: > multiple definition of `the_var'; > tests/bp_signal.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_signal.c:38: > first defined here > > This is a known thing in gcc 10: > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > "Default to -fno-common > > A common mistake in C is omitting extern when declaring a global variable in a > header file. If the header is included by several files it results in multiple > definitions of the same variable. In previous GCC versions this error is > ignored. GCC 10 defaults to -fno-common, which means a linker error will now > be > reported. To fix this, use extern in header files when declaring global > variables, and ensure each global is defined in exactly one C file. As a > workaround, legacy C code can be compiled with -fcommon. > > >int x; // tentative definition - avoid in header files > >extern int y; // correct declaration in a header file" > > > Here are some packages affected: > > > nemo-extensions > https://bugzilla.redhat.com/show_bug.cgi?id=1793470 > > thunarx-python > https://src.fedoraproject.org/rpms/thunarx-python/pull-request/1 > > kernel-tools > https://bugzilla.redhat.com/show_bug.cgi?id=1793473 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1793424 > > gnome-abrt, glusterfs... > > > > Before I go and file dozens of bugzillas, do we want to handle this somehow > better? > > -- > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote: > I've seen this issue pop up in some other packages, as well. > > My elementary-files package is affected, and I think it broke > rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a > lot of ruby packages; though I can't access the build log for the > failed rubygem-ffi build, due to a koji bug relating to side tags). Yes, it should affect around 400 packages in the distro from what I remember from Jeff's test mass rebuild, other distros are aware of it too and the fixes just need to be pushed upstream or grabber from upstream if they are there already. Adding -fcommon is a temporary workaround but fixing the packages is preferred, especially if those fixes end up upstream. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tue, Jan 21, 2020 at 7:36 AM Miro Hrončok wrote: > ... glusterfs... > > glusterfs and nfs-ganesha are already fixed upstream. They'll be fixed in their next minor release before it becomes necessary, or I will respin with patches sooner. -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 21. 01. 20 13:47, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote: I've seen this issue pop up in some other packages, as well. My elementary-files package is affected, and I think it broke rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a lot of ruby packages; though I can't access the build log for the failed rubygem-ffi build, due to a koji bug relating to side tags). Yes, it should affect around 400 packages in the distro from what I remember from Jeff's test mass rebuild Can you please share the list? I'd liek to now how many Python packages are there and analyze whether extension modules built with distutils are affected or not. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: > This is a known thing in gcc 10: > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > "Default to -fno-common > > A common mistake in C is omitting extern when declaring a global variable > in a header file. If the header is included by several files it results in > multiple definitions of the same variable. In previous GCC versions this > error is ignored. GCC 10 defaults to -fno-common, which means a linker > error will now be reported. To fix this, use extern in header files when > declaring global variables, and ensure each global is defined in exactly > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > >int x; // tentative definition - avoid in header files > >extern int y; // correct declaration in a header file" So, for those of us using F31 as the development / test environment, is there a macro that we can add -fno-common to in ~/.rpmmacros without placing it in the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? Looking for an easy way to reproduce this without modifying root owned files. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 21. 01. 20 17:05, Steve Grubb wrote: On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: This is a known thing in gcc 10: https://gcc.gnu.org/gcc-10/porting_to.html#common "Default to -fno-common A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. As a workaround, legacy C code can be compiled with -fcommon. int x; // tentative definition - avoid in header files extern int y; // correct declaration in a header file" So, for those of us using F31 as the development / test environment, is there a macro that we can add -fno-common to in ~/.rpmmacros without placing it in the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? Looking for an easy way to reproduce this without modifying root owned files. You should be able to redefine %__global_compiler_flags in ~/.rpmmacros. It still means you need to copy paste the current flags, but you won't need to touch root owned files. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
> > > > Date: Tue, 21 Jan 2020 11:05:37 -0500 > From: Steve Grubb > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: devel@lists.fedoraproject.org > Cc: Jakub Jelinek > Message-ID: <4127758.jL2Gs7s9Fr@x2> > Content-Type: text/plain; charset="UTF-8" > > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: > > This is a known thing in gcc 10: > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > "Default to -fno-common > > > > A common mistake in C is omitting extern when declaring a global variable > > in a header file. If the header is included by several files it results in > > multiple definitions of the same variable. In previous GCC versions this > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > error will now be reported. To fix this, use extern in header files when > > declaring global variables, and ensure each global is defined in exactly > > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > > > > >int x; // tentative definition - avoid in header files > > > >extern int y; // correct declaration in a header file" > > So, for those of us using F31 as the development / test environment, is there > a macro that we can add -fno-common to in ~/.rpmmacros without placing it in > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? > > Looking for an easy way to reproduce this without modifying root owned files. > > -Steve > > > -- > > Date: Tue, 21 Jan 2020 17:27:20 +0100 > From: Miro Hrončok > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: Steve Grubb , devel@lists.fedoraproject.org > Message-ID: <0f655139-44f5-a0c5-b600-66614c8bd...@redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 21. 01. 20 17:05, Steve Grubb wrote: > > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: > > > This is a known thing in gcc 10: > > > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > > > "Default to -fno-common > > > > > > A common mistake in C is omitting extern when declaring a global variable > > > in a header file. If the header is included by several files it results in > > > multiple definitions of the same variable. In previous GCC versions this > > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > > error will now be reported. To fix this, use extern in header files when > > > declaring global variables, and ensure each global is defined in exactly > > > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > > > > > > > > int x; // tentative definition - avoid in header files > > > > > > extern int y; // correct declaration in a header file" > > > > So, for those of us using F31 as the development / test environment, is > > there > > a macro that we can add -fno-common to in ~/.rpmmacros without placing it in > > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? > > > > Looking for an easy way to reproduce this without modifying root owned > > files. > > You should be able to redefine %__global_compiler_flags in ~/.rpmmacros. > It still means you need to copy paste the current flags, but you won't need > to > touch root owned files. I proposed a change to redhat-rpm-config to handle this case by allowing package to add a single line to their .spec file to turn off the new common symbol handling. Igor rejected that change arguing that the packages themselves should be fixed. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
> > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: > > > This is a known thing in gcc 10: > > > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > > > "Default to -fno-common > > > > > > A common mistake in C is omitting extern when declaring a global variable > > > in a header file. If the header is included by several files it results in > > > multiple definitions of the same variable. In previous GCC versions this > > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > > error will now be reported. To fix this, use extern in header files when > > > declaring global variables, and ensure each global is defined in exactly > > > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > > > > > > > >int x; // tentative definition - avoid in header files > > > > > >extern int y; // correct declaration in a header file" > > > > So, for those of us using F31 as the development / test environment, is > > there > > a macro that we can add -fno-common to in ~/.rpmmacros without placing it in > > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? > > > > Looking for an easy way to reproduce this without modifying root owned > > files. > > > > -Steve > > > > > > -- > > > > Date: Tue, 21 Jan 2020 17:27:20 +0100 > > From: Miro Hrončok > > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > > ... > > To: Steve Grubb , devel@lists.fedoraproject.org > > Message-ID: <0f655139-44f5-a0c5-b600-66614c8bd...@redhat.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 21. 01. 20 17:05, Steve Grubb wrote: > > > On Tuesday, January 21, 2020 7:35:03 AM EST Miro Hrončok wrote: > > > > This is a known thing in gcc 10: > > > > > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > > > > > "Default to -fno-common > > > > > > > > A common mistake in C is omitting extern when declaring a global > > > > variable > > > > in a header file. If the header is included by several files it results > > > > in > > > > multiple definitions of the same variable. In previous GCC versions this > > > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > > > error will now be reported. To fix this, use extern in header files when > > > > declaring global variables, and ensure each global is defined in exactly > > > > one C file. As a workaround, legacy C code can be compiled with > > > > -fcommon. > > > > > > > > > > > > int x; // tentative definition - avoid in header files > > > > > > > > extern int y; // correct declaration in a header file" > > > > > > So, for those of us using F31 as the development / test environment, is > > > there > > > a macro that we can add -fno-common to in ~/.rpmmacros without placing it > > > in > > > the %__global_compiler_flags in /usr/lib/rpm/redhat/macros ? > > > > > > Looking for an easy way to reproduce this without modifying root owned > > > files. > > > > You should be able to redefine %__global_compiler_flags in ~/.rpmmacros. > > It still means you need to copy paste the current flags, but you won't need > > to > > touch root owned files. > I proposed a change to redhat-rpm-config to handle this case by > allowing package to add a single line to their .spec file to turn off > the new common symbol handling. Igor rejected that change arguing that > the packages themselves should be fixed. Ultimately yes they should be fixed, but giving a means of easily mitigating the problem while people work with upstream to fix the issues is also useful, it's been a problem for ever and expecting people to fix it in short order is problematic especially when they'll start to be deluged in FTBFS spam within moments of the mass rebuild. It might also be handy for there to be a heads up bug when the toolchain team first discovers these sorts of issues to give a longer runway for people to be able to engage with upstream to get a fix. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
> > -- > > > Date: Tue, 21 Jan 2020 17:44:37 + > From: Peter Robinson > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: l...@redhat.com, Development discussions related to Fedora > > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > > > I proposed a change to redhat-rpm-config to handle this case by > > allowing package to add a single line to their .spec file to turn off > > the new common symbol handling. Igor rejected that change arguing that > > the packages themselves should be fixed. > > Ultimately yes they should be fixed, but giving a means of easily > mitigating the problem while people work with upstream to fix the > issues is also useful, it's been a problem for ever and expecting > people to fix it in short order is problematic especially when they'll > start to be deluged in FTBFS spam within moments of the mass rebuild. That was the idea. Provide a trivial opt-out so that upstreams had time to fix properly. I even volunteered to add the opt-out marker where appropriate to minimize the FTBFS issues. I also volunteered to help with the packages that don't honor flags injection. > > It might also be handy for there to be a heads up bug when the > toolchain team first discovers these sorts of issues to give a longer > runway for people to be able to engage with upstream to get a fix. I contacted ffesti about 6 weeks ago -- shortly after the commit went upstream GCC and I'd consulted with the SuSE engineers about how they were planning to handle this situation. Sadly I got no response whatsoever from ffesti. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On 21. 01. 20 19:04, Jeff Law wrote: -- Date: Tue, 21 Jan 2020 17:44:37 + From: Peter Robinson Subject: Re: gcc 10: Default to -fno-common, multiple definitions of ... To: l...@redhat.com, Development discussions related to Fedora Message-ID: Content-Type: text/plain; charset="UTF-8" I proposed a change to redhat-rpm-config to handle this case by allowing package to add a single line to their .spec file to turn off the new common symbol handling. Igor rejected that change arguing that the packages themselves should be fixed. Ultimately yes they should be fixed, but giving a means of easily mitigating the problem while people work with upstream to fix the issues is also useful, it's been a problem for ever and expecting people to fix it in short order is problematic especially when they'll start to be deluged in FTBFS spam within moments of the mass rebuild. That was the idea. Provide a trivial opt-out so that upstreams had time to fix properly. I even volunteered to add the opt-out marker where appropriate to minimize the FTBFS issues. I also volunteered to help with the packages that don't honor flags injection. This sounds reasonable to me. The PR is https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 I have reopened it. The mass rebuild will notify the maintainrs and they can use that macro to short-workaround the problem. It' also easier to grep from the specs than custom patches and whatnots. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Tuesday, January 21, 2020 1:16:00 PM EST Miro Hrončok wrote: > I proposed a change to redhat-rpm-config to handle this case by > >>> > >>> allowing package to add a single line to their .spec file to turn off > >>> the new common symbol handling. Igor rejected that change arguing that > >>> the packages themselves should be fixed. > >> > >> Ultimately yes they should be fixed, but giving a means of easily > >> mitigating the problem while people work with upstream to fix the > >> issues is also useful, it's been a problem for ever and expecting > >> people to fix it in short order is problematic especially when they'll > >> start to be deluged in FTBFS spam within moments of the mass rebuild. > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > time to fix properly. I even volunteered to add the opt-out marker > > where appropriate to minimize the FTBFS issues. I also volunteered to > > help with the packages that don't honor flags injection. > > This sounds reasonable to me. > > The PR is > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > I have reopened it. > > The mass rebuild will notify the maintainrs and they can use that macro to > short-workaround the problem. It' also easier to grep from the specs than > custom patches and whatnots I need something like this for suricata. It has about 45 variables causing this. And it's not a simple "extern" addition because it looks like in many cases the variable was never placed in a C file. Simply adding extern keyword leads undefined reference errors. This will take a while to sort out with upstream. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Tue, 2020-01-21 at 13:33 -0500, Steve Grubb wrote: > On Tuesday, January 21, 2020 1:16:00 PM EST Miro Hrončok wrote: > > > > > > I proposed a change to redhat-rpm-config to handle this case by > > > > > > > > > > allowing package to add a single line to their .spec file to turn off > > > > > the new common symbol handling. Igor rejected that change arguing > > > > > that > > > > > the packages themselves should be fixed. > > > > > > > > Ultimately yes they should be fixed, but giving a means of easily > > > > mitigating the problem while people work with upstream to fix the > > > > issues is also useful, it's been a problem for ever and expecting > > > > people to fix it in short order is problematic especially when they'll > > > > start to be deluged in FTBFS spam within moments of the mass rebuild. > > > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > > time to fix properly. I even volunteered to add the opt-out marker > > > where appropriate to minimize the FTBFS issues. I also volunteered to > > > help with the packages that don't honor flags injection. > > > > This sounds reasonable to me. > > > > The PR is > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > > > I have reopened it. > > > > The mass rebuild will notify the maintainrs and they can use that macro to > > short-workaround the problem. It' also easier to grep from the specs than > > custom patches and whatnots > > I need something like this for suricata. It has about 45 variables causing > this. And it's not a simple "extern" addition because it looks like in many > cases the variable was never placed in a C file. Simply adding extern keyword > leads undefined reference errors. This will take a while to sort out with > upstream. You also have to be careful if you're building shared libraries -- I was looking at a package (I forget which) which built multiple DSOs. If you're not careful you can end up with some DSOs which wouldn't have the definition -- worse yet, you're not going to get an undefined symbol when you build those DSOs. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Tue, 2020-01-21 at 19:16 +0100, Miro Hrončok wrote: > On 21. 01. 20 19:04, Jeff Law wrote: > > > -- > > > > > > > > > Date: Tue, 21 Jan 2020 17:44:37 + > > > From: Peter Robinson > > > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > > > ... > > > To: l...@redhat.com, Development discussions related to Fedora > > > > > > Message-ID: > > > > > > Content-Type: text/plain; charset="UTF-8" > > > > > > > > I proposed a change to redhat-rpm-config to handle this case by > > > > allowing package to add a single line to their .spec file to turn off > > > > the new common symbol handling. Igor rejected that change arguing that > > > > the packages themselves should be fixed. > > > > > > Ultimately yes they should be fixed, but giving a means of easily > > > mitigating the problem while people work with upstream to fix the > > > issues is also useful, it's been a problem for ever and expecting > > > people to fix it in short order is problematic especially when they'll > > > start to be deluged in FTBFS spam within moments of the mass rebuild. > > That was the idea. Provide a trivial opt-out so that upstreams had > > time to fix properly. I even volunteered to add the opt-out marker > > where appropriate to minimize the FTBFS issues. I also volunteered to > > help with the packages that don't honor flags injection. > > This sounds reasonable to me. > > The PR is https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > I have reopened it. > > The mass rebuild will notify the maintainrs and they can use that macro to > short-workaround the problem. It' also easier to grep from the specs than > custom > patches and whatnots. Yes, the ability to inspect a .spec file for "violations" was also a benefit -- both in terms of what packages are in need of TLC WRT common symbol handling and in terms of finding packages that are not honoring flags injection. So the question is who makes the final call WRT the change to redhat- rpm-config, particularly given Igor's position? jeff > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
> Date: Tue, 21 Jan 2020 14:00:30 +0100 > From: Miro Hrončok > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: devel@lists.fedoraproject.org, Jakub Jelinek > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > On 21. 01. 20 13:47, Jakub Jelinek wrote: > > On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote: > > > I've seen this issue pop up in some other packages, as well. > > > > > > My elementary-files package is affected, and I think it broke > > > rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a > > > lot of ruby packages; though I can't access the build log for the > > > failed rubygem-ffi build, due to a koji bug relating to side tags). > > > > Yes, it should affect around 400 packages in the distro from what I remember > > from Jeff's test mass rebuild > > Can you please share the list? I'd liek to now how many Python packages are > there and analyze whether extension modules built with distutils are affected > or > not. Sent offlist. Happy to provide to anyone that wants the data, but didn't figure everyone would want it on devel@. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tue, 2020-01-21 at 13:47 +0100, Jakub Jelinek wrote: > On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote: > > I've seen this issue pop up in some other packages, as well. > > > > My elementary-files package is affected, and I think it broke > > rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a > > lot of ruby packages; though I can't access the build log for the > > failed rubygem-ffi build, due to a koji bug relating to side tags). > > Yes, it should affect around 400 packages in the distro from what I remember > from Jeff's test mass rebuild, other distros are aware of it too and the > fixes just need to be pushed upstream or grabber from upstream if they are > there already. > Adding -fcommon is a temporary workaround but fixing the packages is > preferred, especially if those fixes end up upstream. Right. It was ~450. The SuSE team in particular has had reasonable success getting fixes upstreamed -- I think Martin L indicated they'd gotten a few dozen fixed upstream. ISTM that fixing upstream is by far the best choice followed by fixing with a Fedora patch. Working around via an opt-out or modifying the flags in a .spec file is the least desirable. Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
Miro Hrončok wrote: > https://gcc.gnu.org/gcc-10/porting_to.html#common > > "Default to -fno-common > > A common mistake in C is omitting extern when declaring a global variable > in a header file. If the header is included by several files it results in > multiple definitions of the same variable. In previous GCC versions this > error is ignored. GCC 10 defaults to -fno-common, which means a linker > error will now be reported. To fix this, use extern in header files when > declaring global variables, and ensure each global is defined in exactly > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > >int x; // tentative definition - avoid in header files > >extern int y; // correct declaration in a header file" I fail to see how this kind of incompatible change that breaks hundreds of packages (and certainly a lot more software out there) is an improvement. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler wrote: > > Miro Hrončok wrote: > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > "Default to -fno-common > > > > A common mistake in C is omitting extern when declaring a global variable > > in a header file. If the header is included by several files it results in > > multiple definitions of the same variable. In previous GCC versions this > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > error will now be reported. To fix this, use extern in header files when > > declaring global variables, and ensure each global is defined in exactly > > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > > > > >int x; // tentative definition - avoid in header files > > > >extern int y; // correct declaration in a header file" > > I fail to see how this kind of incompatible change that breaks hundreds of > packages (and certainly a lot more software out there) is an improvement. > > Kevin Kofler Honestly, it would have been good to mention that GCC 10 contains such a breaking change, either on the GCC10 Change proposal wiki page, or in the FESCo ticket. Neither was the case. :( Now we still don't have a publicly available list of broken packages (which, apparently, was known?) - can we please get the list? I don't care where, but adding a link to it to either the Change wiki page or the FESCo ticket would be great, so we can better deal with it. Fabio > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 22. 01. 20 12:33, Fabio Valentini wrote: On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler wrote: Miro Hrončok wrote: https://gcc.gnu.org/gcc-10/porting_to.html#common "Default to -fno-common A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. As a workaround, legacy C code can be compiled with -fcommon. int x; // tentative definition - avoid in header files extern int y; // correct declaration in a header file" I fail to see how this kind of incompatible change that breaks hundreds of packages (and certainly a lot more software out there) is an improvement. Kevin Kofler Honestly, it would have been good to mention that GCC 10 contains such a breaking change, either on the GCC10 Change proposal wiki page, or in the FESCo ticket. Neither was the case. :( Now we still don't have a publicly available list of broken packages (which, apparently, was known?) - can we please get the list? I don't care where, but adding a link to it to either the Change wiki page or the FESCo ticket would be great, so we can better deal with it. This is what I got offlist. "This was generated in early December. There may be minor differences due to package updates, deprecations, etc. But this should be 95% complete." 389-ds-base BitchX GMT Macaulay2 NetworkManager R-Rmpfr R-curl R-msm SDL2 abcm2ps abrt acpica-tools adns afpfs-ng aime aircrack-ng alex4 alienarena alliance alltray alpine amanda amora apbs arc argus argyllcms artha atomix atomorun audacity audit awesome ax25-apps ax25-tools axmail biloba bindfs biniax bird bogl bristol bspwm bwa bygfoot c2esp cairo-dock-plug-ins caja camorama carat catimg cdpr cdrkit cellwriter checkpolicy chemtool chocolate-doom clips clonekeen codec2 compat-gdbm compiz-plugins-experimental compiz-plugins-main coreboot-utils coriander crm114 crossfire-client csound cuneiform cups-bjnp cups-filters cylindrix davfs2 denemo device-mapper-multipath dhcp dibbler dieharder dillo distcc dpdk drbd dsi dtc dump dvdisaster e2fsprogs echolinux echoping efax emelfm2 engrampa enlightenment entr envytools epic eqp erlang espeak-ng fatsort fbb fbida fbpanel file-roller fio flashrom flow-tools fontopia foremost foxtrotgps fping fpm2 fprintd freedroid freedroidrpg freeglut frysk funionfs fwknop fwts gabedit galculator gamazons ganglia garden gasnet gauche gball gcin gcolor2 gdbm geeqie geomorph gerbv ggz-gtk-client giis gimp-focusblur-plugin gimp-lqr-plugin gimp-wavelet-denoise-plugin glabels global gluegen2 glusterfs gmic gmsh gnomad2 gnome-abrt gnome-control-center gnudos gnugo gnupg2 gnurobbo goaccess gosnake gplugin gpm gpredict gq gretl greyhounds groonga grsync gsoap gstreamer1-plugins-bad-free gtick gtk4 gtkdialog gtkpod gtkwave gwget halibut hfsplusutils hippo-canvas hitch hnb hping3 htop hydra i3 i3lock ibus-rime ibutils iftop imsettings inadyn-mt infinipath-psm intel-cmt-cat ipmitool iproute iscsi-initiator-utils jamin java-1.8.0-openjdk jfsutils jpilot jumpnbump kabi-dw kbd kitutuki klamav koules lagan lastpass-cli lcdproc lde libacpi libcomps libfabric libgadu libgcroots libiscsi libisds libmemcached libnih libomxil-bellagio libreswan libsepol libtirpc libtpcimgio libtpcmisc libunicap libunwind libva-intel-hybrid-driver libx86emu libxcrypt libxsmm light linsmith liquidwar lldpad logjam logrotate lpsk31 lrslib ltl2ba lttng-tools lttng-ust lwtools lxtask matchbox-window-manager mate-applets mate-utils mboxgrep mbrowse mc mcabber medusa megaglest memcached memkind memtester menu-cache mesa meterbridge mg ming mingw-nsis mingw-qt5-qtbase minicom mirrormagic mlmmj moarvm mod_nss morse2txt mosquitto mot-adms mrxvt mtpaint multican mupdf mydns nacl-arm-binutils naev nagi nagios nas nautilus-python ncdu ncftp ncid ncrack ndctl nebula nekobee-dssi nemo nemo-extensions neovim nethack netsniff-ng neverball nfs-utils nickle ninvaders novacom-server nvml nx-libs nyquist ocaml ocaml-lablgtk ocl-icd open-vm-tools openal-soft openambit opencryptoki opendchub openocd openscap opensips opensmtpd orangefs owfs pacemaker packETH pam_ssh partclone pax pcp phasex pidgin-musictracker pinfo pioneers pipewire planarity pnm2ppa policycoreutils postfix postgresql-pgpool-II prboom prboom-plus proxytunnel pseudo psfex psiconv pvs-sbcl pwmd pypy3 python-caja python-gtkextra qpid-dispatch qstat quagga quake2 qucs raidem ramond rasdaemon ratbox-services rebloom redis rejson rfdump rocksndiamonds roxterm rsyslog rubygem-pam saoimage saphire satyr sawfish sbcl sblim-gather sblim-sfcb sblim-smis-hba scamp scsi-target-utils seamonkey seaview sendmail sextractor shairport-sync sharutils sheepdog shig
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 5:42 AM Miro Hrončok wrote: > > On 22. 01. 20 12:33, Fabio Valentini wrote: > > On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler > > wrote: > >> > >> Miro Hrončok wrote: > >>> https://gcc.gnu.org/gcc-10/porting_to.html#common > >>> > >>> "Default to -fno-common > >>> > >>> A common mistake in C is omitting extern when declaring a global variable > >>> in a header file. If the header is included by several files it results in > >>> multiple definitions of the same variable. In previous GCC versions this > >>> error is ignored. GCC 10 defaults to -fno-common, which means a linker > >>> error will now be reported. To fix this, use extern in header files when > >>> declaring global variables, and ensure each global is defined in exactly > >>> one C file. As a workaround, legacy C code can be compiled with -fcommon. > >>> > >>> > >>> int x; // tentative definition - avoid in header files > >>> > >>> extern int y; // correct declaration in a header file" > >> > >> I fail to see how this kind of incompatible change that breaks hundreds of > >> packages (and certainly a lot more software out there) is an improvement. > >> > >> Kevin Kofler > > > > Honestly, it would have been good to mention that GCC 10 contains such > > a breaking change, either on the GCC10 Change proposal wiki page, or > > in the FESCo ticket. > > Neither was the case. :( > > > > Now we still don't have a publicly available list of broken packages > > (which, apparently, was known?) - can we please get the list? > > I don't care where, but adding a link to it to either the Change wiki > > page or the FESCo ticket would be great, so we can better deal with > > it. > > This is what I got offlist. > > "This was generated in early December. There may be minor differences > due to package updates, deprecations, etc. But this should be 95% > complete." > The list is certainly incomplete. Kernel and kernel-tools are not on it, but don't build due to it. And, the issues don't seem to be "due to updates" rather code that has been there for quite some time. Justin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 22. 01. 20 14:34, Justin Forbes wrote: On Wed, Jan 22, 2020 at 5:42 AM Miro Hrončok wrote: On 22. 01. 20 12:33, Fabio Valentini wrote: On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler wrote: Miro Hrončok wrote: https://gcc.gnu.org/gcc-10/porting_to.html#common "Default to -fno-common A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. As a workaround, legacy C code can be compiled with -fcommon. int x; // tentative definition - avoid in header files extern int y; // correct declaration in a header file" I fail to see how this kind of incompatible change that breaks hundreds of packages (and certainly a lot more software out there) is an improvement. Kevin Kofler Honestly, it would have been good to mention that GCC 10 contains such a breaking change, either on the GCC10 Change proposal wiki page, or in the FESCo ticket. Neither was the case. :( Now we still don't have a publicly available list of broken packages (which, apparently, was known?) - can we please get the list? I don't care where, but adding a link to it to either the Change wiki page or the FESCo ticket would be great, so we can better deal with it. This is what I got offlist. "This was generated in early December. There may be minor differences due to package updates, deprecations, etc. But this should be 95% complete." The list is certainly incomplete. Kernel and kernel-tools are not on it, but don't build due to it. And, the issues don't seem to be "due to updates" rather code that has been there for quite some time. I agree, e.g. pypy3 is on the list but it was never affected. -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok wrote: > On 22. 01. 20 12:33, Fabio Valentini wrote: > > On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler > wrote: > >> > >> Miro Hrončok wrote: > >>> https://gcc.gnu.org/gcc-10/porting_to.html#common > >>> > >>> "Default to -fno-common > >>> > >>> A common mistake in C is omitting extern when declaring a global > variable > >>> in a header file. If the header is included by several files it > results in > >>> multiple definitions of the same variable. In previous GCC versions > this > >>> error is ignored. GCC 10 defaults to -fno-common, which means a linker > >>> error will now be reported. To fix this, use extern in header files > when > >>> declaring global variables, and ensure each global is defined in > exactly > >>> one C file. As a workaround, legacy C code can be compiled with > -fcommon. > >>> > >>> > >>> int x; // tentative definition - avoid in header files > >>> > >>> extern int y; // correct declaration in a header file" > >> > >> I fail to see how this kind of incompatible change that breaks hundreds > of > >> packages (and certainly a lot more software out there) is an > improvement. > >> > >> Kevin Kofler > > > > Honestly, it would have been good to mention that GCC 10 contains such > > a breaking change, either on the GCC10 Change proposal wiki page, or > > in the FESCo ticket. > > Neither was the case. :( > > > > Now we still don't have a publicly available list of broken packages > > (which, apparently, was known?) - can we please get the list? > > I don't care where, but adding a link to it to either the Change wiki > > page or the FESCo ticket would be great, so we can better deal with > > it. > > This is what I got offlist. > > "This was generated in early December. There may be minor differences > due to package updates, deprecations, etc. But this should be 95% > complete." > > 389-ds-base > BitchX > GMT > Macaulay2 > NetworkManager > R-Rmpfr > R-curl > R-msm > SDL2 > abcm2ps > abrt > acpica-tools > adns > afpfs-ng > aime > aircrack-ng > alex4 > alienarena > alliance > alltray > alpine > amanda > amora > apbs > arc > argus > argyllcms > artha > atomix > atomorun > audacity > audit > awesome > ax25-apps > ax25-tools > axmail > biloba > bindfs > biniax > bird > bogl > bristol > bspwm > bwa > bygfoot > c2esp > cairo-dock-plug-ins > caja > camorama > carat > catimg > cdpr > cdrkit > cellwriter > checkpolicy > chemtool > chocolate-doom > clips > clonekeen > codec2 > compat-gdbm > compiz-plugins-experimental > compiz-plugins-main > coreboot-utils > coriander > crm114 > crossfire-client > csound > cuneiform > cups-bjnp > cups-filters > cylindrix > davfs2 > denemo > device-mapper-multipath > dhcp > dibbler > dieharder > dillo > distcc > dpdk > drbd > dsi > dtc > dump > dvdisaster > e2fsprogs > echolinux > echoping > efax > emelfm2 > engrampa > enlightenment > entr > envytools > epic > eqp > erlang > espeak-ng > fatsort > fbb > fbida > fbpanel > file-roller > fio > flashrom > flow-tools > fontopia > foremost > foxtrotgps > fping > fpm2 > fprintd > freedroid > freedroidrpg > freeglut > frysk > funionfs > fwknop > fwts > gabedit > galculator > gamazons > ganglia > garden > gasnet > gauche > gball > gcin > gcolor2 > gdbm > geeqie > geomorph > gerbv > ggz-gtk-client > giis > gimp-focusblur-plugin > gimp-lqr-plugin > gimp-wavelet-denoise-plugin > glabels > global > gluegen2 > glusterfs > gmic > gmsh > gnomad2 > gnome-abrt > gnome-control-center > gnudos > gnugo > gnupg2 > gnurobbo > goaccess > gosnake > gplugin > gpm > gpredict > gq > gretl > greyhounds > groonga > grsync > gsoap > gstreamer1-plugins-bad-free > gtick > gtk4 > gtkdialog > gtkpod > gtkwave > gwget > halibut > hfsplusutils > hippo-canvas > hitch > hnb > hping3 > htop > hydra > i3 > i3lock > ibus-rime > ibutils > iftop > imsettings > inadyn-mt > infinipath-psm > intel-cmt-cat > ipmitool > iproute > iscsi-initiator-utils > jamin > java-1.8.0-openjdk > jfsutils > jpilot > jumpnbump > kabi-dw > kbd > kitutuki > klamav > koules > lagan > lastpass-cli > lcdproc > lde > libacpi > libcomps > libfabric > libgadu > libgcroots > libiscsi > libisds > libmemcached > libnih > libomxil-bellagio > libreswan > libsepol > libtirpc > libtpcimgio > libtpcmisc > libunicap > libunwind > libva-intel-hybrid-driver > libx86emu > libxcrypt > libxsmm > light > linsmith > liquidwar > lldpad > logjam > logrotate > lpsk31 > lrslib > ltl2ba > lttng-tools > lttng-ust > lwtools > lxtask > matchbox-window-manager > mate-applets > mate-utils > mboxgrep > mbrowse > mc > mcabber > medusa > megaglest > memcached > memkind > memtester > menu-cache > mesa > meterbridge > mg > ming > mingw-nsis > mingw-qt5-qtbase > minicom > mirrormagic > mlmmj > moarvm > mod_nss > morse2txt > mosquitto > mot-adms > mrxvt > mtpaint > multican > mupdf > mydns > nacl-arm-binutils > naev > nagi > nagios > nas > nautilus-python > ncdu > ncftp > ncid > ncrack > ndctl > nebula > nekobee-dssi > nemo > nemo-extensions > n
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, 22 Jan 2020 at 14:54, Christoph Junghans wrote: > > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok wrote: >> >> jtaylornetsniff-ng ocaml-lablgtk suricata >> junghans gasnet > > Sorry, how do I install gcc10 on Rawhide? > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it. > > Christoph > >> Going from a similar discussion in #fedora-devel. There has been no current compose of rawhide so it can not be synced out of the mirror. In order to upgrade/install gcc10 you will need to enable the local repo in mock or replicate it on your system. 2020-01-21 18:33:05 fedora-32 is still at gcc-9.2.1, but I got an em ail saying cjdns no longer builds with gcc-10. How do I rebuild with gcc-10 to get this fixed? I assume the goal is to get most packages ready for gcc-10 befo re upgrading rawhide. 2020-01-21 18:58:03 sdgathman: rawhide/f32 already has gcc-10... the re just hasn't been a successfull rawhide compose syncing it out to mirrors. You can do scratch builds or you could enable the 'local' repo in mock to use the k oji buildroot... -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 1:31 PM Stephen John Smoogen wrote: > On Wed, 22 Jan 2020 at 14:54, Christoph Junghans > wrote: > > > > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok > wrote: > >> > > >> jtaylornetsniff-ng ocaml-lablgtk suricata > >> junghans gasnet > > > > Sorry, how do I install gcc10 on Rawhide? > > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it. > > > > Christoph > > > >> > > Going from a similar discussion in #fedora-devel. There has been no > current compose of rawhide so it can not be synced out of the mirror. > In order to upgrade/install gcc10 you will need to enable the local > repo in mock or replicate it on your system. > I see and how do I do that? > > 2020-01-21 18:33:05 fedora-32 is still at gcc-9.2.1, but I got > an em > ail saying cjdns no longer builds with gcc-10. How do I rebuild with > gcc-10 to > get this fixed? I assume the goal is to get most packages ready for > gcc-10 befo > re upgrading rawhide. > 2020-01-21 18:58:03 sdgathman: rawhide/f32 already has > gcc-10... the > re just hasn't been a successfull rawhide compose syncing it out to > mirrors. You > can do scratch builds or you could enable the 'local' repo in mock to use > the k > oji buildroot... > > > -- > Stephen J Smoogen. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Christoph Junghans Web: http://www.compphys.de ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 9:58 PM Christoph Junghans wrote: > > > > On Wed, Jan 22, 2020 at 1:31 PM Stephen John Smoogen wrote: >> >> On Wed, 22 Jan 2020 at 14:54, Christoph Junghans wrote: >> > >> > On Wed, Jan 22, 2020 at 4:42 AM Miro Hrončok wrote: >> >> >> >> >> jtaylornetsniff-ng ocaml-lablgtk suricata >> >> junghans gasnet >> > >> > Sorry, how do I install gcc10 on Rawhide? >> > "dnf upgrade --advisory=FEDORA-2020-a165791b6f" doesn't seem to do it. >> > >> > Christoph >> > >> >> >> >> Going from a similar discussion in #fedora-devel. There has been no >> current compose of rawhide so it can not be synced out of the mirror. >> In order to upgrade/install gcc10 you will need to enable the local >> repo in mock or replicate it on your system. > > I see and how do I do that? Assuming you want to use x86_64: mock -r fedora-rawhide-x86_64 --enablerepo=local foo_src.rpm Fabio >> >> >> 2020-01-21 18:33:05 fedora-32 is still at gcc-9.2.1, but I got >> an em >> ail saying cjdns no longer builds with gcc-10. How do I rebuild with gcc-10 >> to >> get this fixed? I assume the goal is to get most packages ready for gcc-10 >> befo >> re upgrading rawhide. >> 2020-01-21 18:58:03 sdgathman: rawhide/f32 already has gcc-10... >> the >> re just hasn't been a successfull rawhide compose syncing it out to mirrors. >> You >> can do scratch builds or you could enable the 'local' repo in mock to use >> the k >> oji buildroot... >> >> >> -- >> Stephen J Smoogen. >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > > -- > Christoph Junghans > Web: http://www.compphys.de > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 1/21/20 6:35 AM, Miro Hrončok wrote: This is a known thing in gcc 10: https://gcc.gnu.org/gcc-10/porting_to.html#common I have seen odd behavior in Wine with this change. Some code compiles successfully without requiring extern in x86 / x86_64 but the same code requires extern for armv7hl. :-/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Tuesday, 21 January 2020 13:35:03 CET Miro Hrončok wrote: > Hello, > > we try to rebuild all Python packages against Python 3.9 and report the > failures. I've seen several similar failures in a row now that can be > reproduced in Fedora rawhide with the new gcc version. > > ld errors on multiple definitions of ..., for example: > > ld: > tests/bp_account.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/per > f/tests/bp_account.c:22: multiple definition of `the_var'; > tests/bp_signal.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf > /tests/bp_signal.c:38: first defined here > > This is a known thing in gcc 10: > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > "Default to -fno-common > > A common mistake in C is omitting extern when declaring a global variable in > a header file. If the header is included by several files it results in > multiple definitions of the same variable. In previous GCC versions this > error is ignored. GCC 10 defaults to -fno-common, which means a linker > error will now be reported. To fix this, use extern in header files when > declaring global variables, and ensure each global is defined in exactly > one C file. As a workaround, legacy C code can be compiled with -fcommon. > > >int x; // tentative definition - avoid in header files > >extern int y; // correct declaration in a header file" > > > Here are some packages affected: > > > nemo-extensions > https://bugzilla.redhat.com/show_bug.cgi?id=1793470 > > thunarx-python > https://src.fedoraproject.org/rpms/thunarx-python/pull-request/1 > > kernel-tools > https://bugzilla.redhat.com/show_bug.cgi?id=1793473 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1793424 > > gnome-abrt, glusterfs... > > > > Before I go and file dozens of bugzillas, do we want to handle this somehow > better? > -- > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List > Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org How to fix the affected packages? For some I ised extern and it worked but for other using extern resulted in error like: /usr/bin/ld: /builddir/build/BUILD/uTox-0.17.1/src/xlib/main.c:590: undefined reference to `font_small_lineheight' Lots of undefined reference despite the var being marked as global. All the packages I have to fix have deadish upstream. Any help appreciated. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
Well sure, because you need one, and only one, file that actually defines it. Previously every file that included the header created a definition which meant you could wind up with multiple definitions if more than one file included it. Now no file that includes the header will create a definition unless the file contains a definition of the variable (ie without extern) so if there isn't such a file already then you will need to choose an appropriate file and add the definition to it. Tom On 23/01/2020 15:48, Robert-André Mauchin wrote: On Tuesday, 21 January 2020 13:35:03 CET Miro Hrončok wrote: Hello, we try to rebuild all Python packages against Python 3.9 and report the failures. I've seen several similar failures in a row now that can be reproduced in Fedora rawhide with the new gcc version. ld errors on multiple definitions of ..., for example: ld: tests/bp_account.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/per f/tests/bp_account.c:22: multiple definition of `the_var'; tests/bp_signal.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf /tests/bp_signal.c:38: first defined here This is a known thing in gcc 10: https://gcc.gnu.org/gcc-10/porting_to.html#common "Default to -fno-common A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. As a workaround, legacy C code can be compiled with -fcommon. int x; // tentative definition - avoid in header files extern int y; // correct declaration in a header file" Here are some packages affected: nemo-extensions https://bugzilla.redhat.com/show_bug.cgi?id=1793470 thunarx-python https://src.fedoraproject.org/rpms/thunarx-python/pull-request/1 kernel-tools https://bugzilla.redhat.com/show_bug.cgi?id=1793473 https://bugzilla.redhat.com/show_bug.cgi?id=1793424 gnome-abrt, glusterfs... Before I go and file dozens of bugzillas, do we want to handle this somehow better? -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org How to fix the affected packages? For some I ised extern and it worked but for other using extern resulted in error like: /usr/bin/ld: /builddir/build/BUILD/uTox-0.17.1/src/xlib/main.c:590: undefined reference to `font_small_lineheight' Lots of undefined reference despite the var being marked as global. All the packages I have to fix have deadish upstream. Any help appreciated. Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Thu, Jan 23, 2020 at 04:48:14PM +0100, Robert-André Mauchin wrote: > How to fix the affected packages? For some I ised extern and it worked but > for > other using extern resulted in error like: > > /usr/bin/ld: /builddir/build/BUILD/uTox-0.17.1/src/xlib/main.c:590: undefined > reference to `font_small_lineheight' > > Lots of undefined reference despite the var being marked as global. All the > packages I have to fix have deadish upstream. See https://gcc.gnu.org/gcc-10/porting_to.html#common The variables should be declared with extern in the header files and defined somewhere, in a single C source file. Which one really depends on what is the variable for, and what uses it. This is similar to C++, where common vars weren't supported (in standard C they aren't either), except that in C++17 and later there are inline variables, so also in C++ if you have (not in template) static data member declared in some header, you need to provide a definition in a single source file. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Tuesday, January 21, 2020 1:52:54 PM EST Jeff Law wrote: > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > > > time to fix properly. I even volunteered to add the opt-out marker > > > > where appropriate to minimize the FTBFS issues. I also volunteered > > > > to help with the packages that don't honor flags injection. > > > > > > This sounds reasonable to me. > > > > > > The PR is > > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > > > > > I have reopened it. > > > > > > The mass rebuild will notify the maintainrs and they can use that macro > > > to short-workaround the problem. It' also easier to grep from the specs > > > than custom patches and whatnots > > > > I need something like this for suricata. It has about 45 variables > > causing this. And it's not a simple "extern" addition because it looks > > like in many cases the variable was never placed in a C file. Simply > > adding extern keyword leads undefined reference errors. This will take a > > while to sort out with upstream. > > You also have to be careful if you're building shared libraries -- I > was looking at a package (I forget which) which built multiple DSOs. > If you're not careful you can end up with some DSOs which wouldn't have > the definition -- worse yet, you're not going to get an undefined > symbol when you build those DSOs. So, I have a weird one. I'm compiling audit and getting multiple definitions. I have /usr/bin/ld: ausearch-checkpt.o:/home/sgrubb/working/BUILD/audit-3.0/src/ ausearch-common.h:53: multiple definition of `event_node_list'; ausearch.o:/ home/sgrubb/working/BUILD/audit-3.0/src/ausearch-common.h:53: first defined here $ cat ausearch-checkpt.c | grep event_node_list Hmm. Nothing found. $ objdump --syms ausearch-checkpt.o | grep event_node_list 0040 g O .bss 0008 event_node_list It's in the object file? In ausearch-checkpt.c we have #include "ausearch- checkpt.h which does not define it. That file has #include "ausearch-llist.h" which does not define it. That file has #include "ausearch-common.h" which does define it as: extern slist *event_node_list; So, what appears to be happening is all these C files are creating a definition based on this and they don't even use this variable. It seems like they would create a spot in their table *if and only if* it was referenced somewhere in the code. I'm not sure if this was intended but it will be a big problem for everyone. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Thu, 2020-01-23 at 17:23 -0500, Steve Grubb wrote: > On Tuesday, January 21, 2020 1:52:54 PM EST Jeff Law wrote: > > > > > That was the idea. Provide a trivial opt-out so that upstreams had > > > > > time to fix properly. I even volunteered to add the opt-out marker > > > > > where appropriate to minimize the FTBFS issues. I also volunteered > > > > > to help with the packages that don't honor flags injection. > > > > > > > > This sounds reasonable to me. > > > > > > > > The PR is > > > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/77 > > > > > > > > I have reopened it. > > > > > > > > The mass rebuild will notify the maintainrs and they can use that macro > > > > to short-workaround the problem. It' also easier to grep from the specs > > > > than custom patches and whatnots > > > > > > I need something like this for suricata. It has about 45 variables > > > causing this. And it's not a simple "extern" addition because it looks > > > like in many cases the variable was never placed in a C file. Simply > > > adding extern keyword leads undefined reference errors. This will take a > > > while to sort out with upstream. > > > > You also have to be careful if you're building shared libraries -- I > > was looking at a package (I forget which) which built multiple DSOs. > > If you're not careful you can end up with some DSOs which wouldn't have > > the definition -- worse yet, you're not going to get an undefined > > symbol when you build those DSOs. > > So, I have a weird one. I'm compiling audit and getting multiple definitions. > > I have > > /usr/bin/ld: ausearch-checkpt.o:/home/sgrubb/working/BUILD/audit-3.0/src/ > ausearch-common.h:53: multiple definition of `event_node_list'; ausearch.o:/ > home/sgrubb/working/BUILD/audit-3.0/src/ausearch-common.h:53: first defined > here > > $ cat ausearch-checkpt.c | grep event_node_list > > Hmm. Nothing found. > > $ objdump --syms ausearch-checkpt.o | grep event_node_list > 0040 g O .bss 0008 event_node_list > > It's in the object file? In ausearch-checkpt.c we have #include "ausearch- > checkpt.h which does not define it. That file has #include "ausearch-llist.h" > which does not define it. That file has #include "ausearch-common.h" which > does > define it as: > > extern slist *event_node_list; > > So, what appears to be happening is all these C files are creating a > definition > based on this and they don't even use this variable. It seems like they would > create a spot in their table *if and only if* it was referenced somewhere in > the code. I'm not sure if this was intended but it will be a big problem for > everyone. Use -save-temps and post the .i file. An "extern blah blah blah" should not be doing that. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of
On Thursday, January 23, 2020 5:30:28 PM EST Jeff Law wrote: > On Thu, 2020-01-23 at 17:23 -0500, Steve Grubb wrote: > > On Tuesday, January 21, 2020 1:52:54 PM EST Jeff Law wrote: > > > > > > That was the idea. Provide a trivial opt-out so that upstreams > > > > > > had > > > > > > time to fix properly. I even volunteered to add the opt-out > > > > > > marker > > > > > > where appropriate to minimize the FTBFS issues. I also > > > > > > volunteered > > > > > > to help with the packages that don't honor flags injection. > > > > > > > > > > This sounds reasonable to me. > > > > > > > > > > The PR is > > > > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/7 > > > > > 7 > > > > > > > > > > I have reopened it. > > > > > > > > > > The mass rebuild will notify the maintainrs and they can use that > > > > > macro > > > > > to short-workaround the problem. It' also easier to grep from the > > > > > specs > > > > > than custom patches and whatnots > > > > > > > > I need something like this for suricata. It has about 45 variables > > > > causing this. And it's not a simple "extern" addition because it > > > > looks > > > > like in many cases the variable was never placed in a C file. Simply > > > > adding extern keyword leads undefined reference errors. This will > > > > take a > > > > while to sort out with upstream. > > > > > > You also have to be careful if you're building shared libraries -- I > > > was looking at a package (I forget which) which built multiple DSOs. > > > If you're not careful you can end up with some DSOs which wouldn't have > > > the definition -- worse yet, you're not going to get an undefined > > > symbol when you build those DSOs. > > > > So, I have a weird one. I'm compiling audit and getting multiple > > definitions. > > > > I have > > > > /usr/bin/ld: ausearch-checkpt.o:/home/sgrubb/working/BUILD/audit-3.0/src/ > > ausearch-common.h:53: multiple definition of `event_node_list'; > > ausearch.o:/ > > home/sgrubb/working/BUILD/audit-3.0/src/ausearch-common.h:53: first > > defined here > > > > $ cat ausearch-checkpt.c | grep event_node_list > > > > Hmm. Nothing found. > > > > $ objdump --syms ausearch-checkpt.o | grep event_node_list > > 0040 g O .bss 0008 event_node_list > > > > It's in the object file? In ausearch-checkpt.c we have #include > > "ausearch- > > checkpt.h which does not define it. That file has #include > > "ausearch-llist.h" which does not define it. That file has #include > > "ausearch-common.h" which does define it as: > > > > extern slist *event_node_list; > > > > So, what appears to be happening is all these C files are creating a > > definition based on this and they don't even use this variable. It seems > > like they would create a spot in their table *if and only if* it was > > referenced somewhere in the code. I'm not sure if this was intended but > > it will be a big problem for everyone. > > Use -save-temps and post the .i file. > > An "extern blah blah blah" should not be doing that. That was very helpful. Thanks. Turns out the build testing I was doing was using a Fedora spec file instead of my upstream spec file which means it was untarring the wrong file instead of the freshly fixed file. That -save-temps option might help me figure out some missing definitions in suricata. Thanks, -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On Wed, Jan 22, 2020 at 12:41:24PM +0100, Miro Hrončok wrote: > ocaml I just did a scratch build of OCaml in Rawhide and it seems fine. I guess it may have FTBFS at that time for some other reason, but without seeing the logs it's hard to tell. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gcc 10: Default to -fno-common, multiple definitions of ...
On 21. 01. 20 13:35, Miro Hrončok wrote: Hello, we try to rebuild all Python packages against Python 3.9 and report the failures. I've seen several similar failures in a row now that can be reproduced in Fedora rawhide with the new gcc version. ld errors on multiple definitions of ..., for example: ld: tests/bp_account.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_account.c:22: multiple definition of `the_var'; tests/bp_signal.o:/builddir/build/BUILD/kernel-5.4.fc32/linux-5.4/tools/perf/tests/bp_signal.c:38: first defined here This is a known thing in gcc 10: https://gcc.gnu.org/gcc-10/porting_to.html#common "Default to -fno-common A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. As a workaround, legacy C code can be compiled with -fcommon. int x; // tentative definition - avoid in header files extern int y; // correct declaration in a header file" Those of you who need a temporary workaround, follow: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md#legacy-fcommon (The section is called "Legacy -fcommon" in case the anchor link doesn't work for you (it doesn't work for me).) -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Re: gcc 10: Default to -fno-common, multiple definitions of ...
> Date: Wed, 22 Jan 2020 07:34:01 -0600 > From: Justin Forbes > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > ... > To: Development discussions related to Fedora > > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Wed, Jan 22, 2020 at 5:42 AM Miro Hrončok wrote: > > On 22. 01. 20 12:33, Fabio Valentini wrote: > > > On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler > > > wrote: > > > > Miro Hrončok wrote: > > > > > https://gcc.gnu.org/gcc-10/porting_to.html#common > > > > > > > > > > "Default to -fno-common > > > > > > > > > > A common mistake in C is omitting extern when declaring a global > > > > > variable > > > > > in a header file. If the header is included by several files it > > > > > results in > > > > > multiple definitions of the same variable. In previous GCC versions > > > > > this > > > > > error is ignored. GCC 10 defaults to -fno-common, which means a linker > > > > > error will now be reported. To fix this, use extern in header files > > > > > when > > > > > declaring global variables, and ensure each global is defined in > > > > > exactly > > > > > one C file. As a workaround, legacy C code can be compiled with > > > > > -fcommon. > > > > > > > > > > > > > > > int x; // tentative definition - avoid in header files > > > > > > > > > > extern int y; // correct declaration in a header file" > > > > > > > > I fail to see how this kind of incompatible change that breaks hundreds > > > > of > > > > packages (and certainly a lot more software out there) is an > > > > improvement. > > > > > > > > Kevin Kofler > > > > > > Honestly, it would have been good to mention that GCC 10 contains such > > > a breaking change, either on the GCC10 Change proposal wiki page, or > > > in the FESCo ticket. > > > Neither was the case. :( > > > > > > Now we still don't have a publicly available list of broken packages > > > (which, apparently, was known?) - can we please get the list? > > > I don't care where, but adding a link to it to either the Change wiki > > > page or the FESCo ticket would be great, so we can better deal with > > > it. > > > > This is what I got offlist. > > > > "This was generated in early December. There may be minor differences > > due to package updates, deprecations, etc. But this should be 95% > > complete." > > > The list is certainly incomplete. Kernel and kernel-tools are not on > it, but don't build due to it. And, the issues don't seem to be "due > to updates" rather code that has been there for quite some time. So to give everyone a bit of background on the tester. It's primary purpose is to identify GCC issues by building all the Fedora packages with the weekly GCC development snapshot. My time is limited, so to avoid digging into issues that aren't really related to the GCC development snapshot under testing the process works like this: 1. Build a package using the development snapshot (using mock and a priority repo so that my GCC package is selected before the standard tools). If that build succeeds, then we're done and happy. 2. If the build in step #1 fails, then we try the build again, but this time without the priority repo. So we're building with the standard Fedora tools. If this build succeeds, then the package is considered as failing and gets investigated as it's highly likely there's a GCC bug that needs addressing. However, if this control build also fails, then there's a problem of some sort with the package itself or other tools in the buildroot. And given my time is limited and the purpose of my tester is to find GCC development bugs, if the control build fails, then it's not typically investigated. Typically there's around ~500 packages that fail their control build at any given time. I know I've seen kernel and kernel-tools in that bucket from time to time. My logs don't go back far enough to know the state of kernel and kernel-tools in early December when that list was generated. In the run with last week's GCC snapshot, both the kernel and kernel-tools worked with gcc-10 (they failed LTO, but that's totally separate from the common symbol issues we're discussing now). Jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
