Re: xtables problem

Re: xtables problem

[John Haxby]

John Haxby wrote:
>
> $ ./configure --with-kbuild=/lib/modules/2.6.27.6/build
> $ make
> ...
>  CC       libxt_CHAOS.oo
>  CCLD     libxt_CHAOS.so
> libxt_CHAOS.oo: In function `_init':
> /home/jch/rpmbuild/BUILD/xtables-addons-1.6/extensions/libxt_CHAOS.c:112: 
> multiple definition of `_init'
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/crti.o:(.init+0x0): 
> first defined here
> collect2: ld returned 1 exit status

You can go off a distro, you really can:

* Mon Feb 11 2008 Thomas Woerner <twoerner@redhat.com> 1.4.0-1
- new version 1.4.0
- fixed condrestart (rhbz#428148)
- report the module in rmmod_r if there is an error
- use nf_ext_init instead of my_init for extension constructors


The description is possibly a little wrong because the upshot is that in 
<xtables.h> "_INIT" and the subsequent definition of "_init" are 
replaced with "NF_EXT_INIT" and "nf_ext_init" respectively.  Neither 
Google nor Red Hat's bugzilla offer any readily findable explanation of 
this all I found was quite a few copies of the same comment in various 
different RPMs.

The only thing that springs to mind is that variables and C-preprocessor 
names whose names begin with "_" are reserved by C and you shouldn't use 
them.

If Thomas is listening, can you shed any light?

Would it not be nice, as well, if iptables and xtables could come to an 
agreement over what is the right thing to do.  I'm surely not the first 
person to come unstuck with this. 

Right, back to building an RPM from this thing.

jch

Re: xtables-addons problem

[Jan Engelhardt]

On Thursday 2008-11-20 16:30, John Haxby wrote:

> John Haxby wrote:
>>
>> $ ./configure --with-kbuild=/lib/modules/2.6.27.6/build
>> $ make
>> ...
>>  CC       libxt_CHAOS.oo
>>  CCLD     libxt_CHAOS.so
>> libxt_CHAOS.oo: In function `_init':
>> /home/jch/rpmbuild/BUILD/xtables-addons-1.6/extensions/libxt_CHAOS.c:112:
>> multiple definition of `_init'
>> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/crti.o:(.init+0x0):
>> first defined here
>> collect2: ld returned 1 exit status
>
> You can go off a distro, you really can:

(It took a while to get this... it's supposed to say)
	You can go off _on_ a distro, you really can.
Yes indeed.

> The only thing that springs to mind is that variables and 
> C-preprocessor names whose names begin with "_" are reserved by C and 
> you shouldn't use them.
>
> If Thomas is listening, can you shed any light?
>
> Would it not be nice, as well, if iptables and xtables could come to 
> an agreement over what is the right thing to do.

(a) the iptables userspace package uses _init

(b) xtables is a generic term for protocol-independent code/components

(c) xtables-addons's kernel parts are based on an unmodified kernel 
source.

(d) xtables-addons's userspace parts are based on an unmodified iptables 
source.

> * Mon Feb 11 2008 Thomas Woerner <twoerner@redhat.com> 1.4.0-1
> - new version 1.4.0
> - fixed condrestart (rhbz#428148)
> - report the module in rmmod_r if there is an error
> - use nf_ext_init instead of my_init for extension constructors

Not only did RedHat manage to blow up on (c) for RHEL5/CentOS because of 
excessive backporting, but now they also crippled their iptables 
package with that nf_ext_init, breaking ALL extensions out there.

I wonder how they managed to not break the compilation of the
extensions inside the iptables package -- because these continue to
use _init and its substitution was just nuked by that patch.

Re: xtables problem

[John Haxby]

John Haxby wrote:
> $ ./configure --with-kbuild=/lib/modules/2.6.27.6/build
> $ make
> ...
>  CC       libxt_CHAOS.oo
>  CCLD     libxt_CHAOS.so
> libxt_CHAOS.oo: In function `_init':
> /home/jch/rpmbuild/BUILD/xtables-addons-1.6/extensions/libxt_CHAOS.c:112: 
> multiple definition of `_init'
> /usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../lib64/crti.o:(.init+0x0): 
> first defined here
> collect2: ld returned 1 exit status

I've submitted a bug report for this: 
https://bugzilla.redhat.com/show_bug.cgi?id=472548

Looking through this history of changes, it seems that this was a 
well-intentioned fix as part of moving from "ld -shared" to "gcc 
-shared" a while back (1.3.4 time) that accidentally got carried forward 
even though it wasn't needed due to changes in iptables.

jch