> 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
