12:04 p.m.
----------------------------------------------------------------------
Date: Tue, 21 Jan 2020 17:44:37 +0000
From: Peter Robinson <pbrobinson(a)gmail.com>
Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
...
To: law(a)redhat.com, Development discussions related to Fedora
<devel(a)lists.fedoraproject.org>
Message-ID:
<CALeDE9Pn=ZpqT89F4gSiZh7hf_W8ho9yLjD1ZeyMXxat367vbw(a)mail.gmail.com>
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
12:16 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
On 21. 01. 20 19:04, Jeff Law wrote:
>
> ----------------------------------------------------------------------
>
>
> Date: Tue, 21 Jan 2020 17:44:37 +0000
> From: Peter Robinson <pbrobinson(a)gmail.com>
> Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> ...
> To: law(a)redhat.com, Development discussions related to Fedora
> <devel(a)lists.fedoraproject.org>
> Message-ID:
> <CALeDE9Pn=ZpqT89F4gSiZh7hf_W8ho9yLjD1ZeyMXxat367vbw(a)mail.gmail.com>
> 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
12:33 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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
12:52 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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
4:23 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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
0000000000000040 g O .bss 0000000000000008 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
4:30 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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
0000000000000040 g O .bss 0000000000000008 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
4:52 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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
> 0000000000000040 g O .bss 0000000000000008 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
1:34 p.m.
New subject: gcc 10: Default to -fno-common, multiple definitions of
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 +0000
> > From: Peter Robinson <pbrobinson(a)gmail.com>
> > Subject: Re: gcc 10: Default to -fno-common, multiple definitions of
> > ...
> > To: law(a)redhat.com, Development discussions related to Fedora
> > <devel(a)lists.fedoraproject.org>
> > Message-ID:
> > <CALeDE9Pn=ZpqT89F4gSiZh7hf_W8ho9yLjD1ZeyMXxat367vbw(a)mail.gmail.com>
> > 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
1554
days inactive
1556
days old
7 comments
3 participants
participants (3)
-
Jeff Law -
Miro Hrončok -
Steve Grubb