> 
> 
> 
> Date: Tue, 21 Jan 2020 11:05:37 -0500
> From: Steve Grubb <sgr...@redhat.com>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>       ...
> To: devel@lists.fedoraproject.org
> Cc: Jakub Jelinek <ja...@redhat.com>
> 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 <mhron...@redhat.com>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
>       ...
> To: Steve Grubb <sgr...@redhat.com>, 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

Reply via email to