> > 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 <mhroncok@xxxxxxxxxx> > > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of > > ... > > To: Steve Grubb <sgrubb@xxxxxxxxxx>, devel@xxxxxxxxxxxxxxxxxxxxxxx > > Message-ID: <0f655139-44f5-a0c5-b600-66614c8bd6d6@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
