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

[Miro Hrončok]

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: gcc 10: Default to -fno-common, multiple definitions of ...

[Richard W.M. Jones]

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

[Steve Grubb]

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

[Jeff Law]

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

[Steve Grubb]

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 ...

[Jakub Jelinek]

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 ...

[Tom Hughes]

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 ...

[Robert-André Mauchin]

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 ...

[Michael Cronenworth]

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 ...

[Fabio Valentini]

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 ...

[Christoph Junghans]

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 ...

[Stephen John Smoogen]

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 ...

[Christoph Junghans]

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: Re: gcc 10: Default to -fno-common, multiple definitions of ...

[Jeff Law]

> 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

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

[Miro Hrončok]

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 ...

[Justin Forbes]

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 ...

[Miro Hrončok]

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 ...

[Fabio Valentini]

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 ...

[Kevin Kofler]

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 ...

[Jeff Law]

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 ...

[Jeff Law]

> 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

[Jeff Law]

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

[Jeff Law]

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

[Steve Grubb]

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

[Miro Hrončok]

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

[Jeff Law]

> 
> --
> 
> 
> 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 ...

[Peter Robinson]

> > 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 ...

[Jeff Law]

> 
> 
> 
> 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 ...

[Miro Hrončok]

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 ...

[Steve Grubb]

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 ...

[Miro Hrončok]

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 ...

[Kaleb Keithley]

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 ...

[Jakub Jelinek]

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 ...

[Fabio Valentini]

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