xtables problem

I'm ashamed to say I can't build xtables-addons. I'm at a bit of a loss, but this is what I get:

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

It's the end of a long day, so I'm probably doing something stupidly wrong. If anyone can point out the error of my ways I'd be most grateful.

jch

You can go off a distro, you really can:

* Mon Feb 11 2008 Thomas Woerner <[email protected]> 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

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

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

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.

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