Re: Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Date: Wed, 22 Jan 2020 07:34:01 -0600
> From: Justin Forbes <jmforbes@xxxxxxxxxxx>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> 	...
> To: Development discussions related to Fedora
> 	<devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Message-ID:
> 	<CAFxkdArNW8CS+rv7TJKB1bV0ED7xLsUHDgi5z6Wugi5kKZMVgA@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Wed, Jan 22, 2020 at 5:42 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
> > On 22. 01. 20 12:33, Fabio Valentini wrote:
> > > On Wed, Jan 22, 2020 at 12:12 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux