Description of problem: When attempting to compile, for example, the xtables-addons I get compilation errors relating to a redefinition of _init. Version-Release number of selected component (if applicable): iptables-devel-1.4.1.1-2.fc9.x86_64 How reproducible: Everytime Steps to Reproduce: 1. Download xtables-addons from http://jengelh.medozas.de/projects/xtables/ 2. ./configure 3. make Actual results: ... 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 Expected results: Successful compilation Additional info: This error comes from the nf_ext_init patch that was introduced in 1.4.0-1: * Mon Feb 11 2008 Thomas Woerner <twoerner> 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 This seems to be because of an earlier change: * Fri Nov 25 2005 Thomas Woerner <twoerner> 1.3.4-2 - fix for plugin problem: link with "gcc -shared" instead of "ld -shared" and replace "_init" with "__attribute((constructor)) my_init" but actually this is not needed because the compilation of an extension shared library is done using "-D_INIT=lib$*_init" from the GNUmakefile and this means that what looks like an unpermitted _init() in the source for the shared library is replaced by, for example, libipt_DNAT_init() and similarly for other shared libraries. These perl invocations in the .spec file sort-of work around the problem: # fix constructor names, see also nf_ext_init patch perl -pi -e "s/void _init\(/void __attribute\(\(constructor\)\) nf_ext_init\(/g" extensions/*.c perl -pi -e "s/^_init\(/__attribute\(\(constructor\)\) nf_ext_init\(/g" extensions/*.c Because they redefine the _init() function to nf_ext_init() which in turn is defined as NF_EXT_INIT() and completely sidesteps the intent of this stanza in <xtables.h> #ifdef NO_SHARED_LIBS # ifdef _INIT # undef _init # define _init _INIT # endif extern void init_extensions(void); #else # define _init __attribute__((constructor)) _INIT #endif (this is the unpatched version). As you can see, with the -D_INIT=lib$*_init in the normal compilation this will result in, for example, void _init (void) being replaced with void __attribute__((constructor)) _INIT (void) which in turn is replaced with void __attribute__((constructor)) libipt_DNAT_init (void) for the DNAT extension. To avoid other people wasting several hours trying to get to the bottom of weird compilation errors when compiling xtables-addons I'd suggest simply getting rid of the nf_ext_init patch. (Actually, I think what tends to happen is that people swear at Fedora in general and build their own iptables which replaces <xtables.h> and fixes the problem without understanding what's going on.
Created attachment 324326 [details] Proposed patch This patch removes the no longer needed nf_ext_init() patch.
That is an appalling description, sorry. What I should have said is that the "my_init" patch introduced in 1.3.4-2 and subsequently modified to an nf_ext_init patch in 1.4.0-1 actually causes problems when trying to compile, for example, the xtables-addons suite. This change was originally to avoid using a function called _init() in a shared library which isn't permitted when you're (correctly) building a shared library with "gcc -shared". While you'd done that, the upstream iptables fixed the problem in a different way and now we have a bit of a problem that causes conventionally written iptables extensions to fail to compile (as you can see from the failure to build xtables-addons). My suggested fix is to simply drop the nf_ext_init patch as it's no longer needed. Sorry I made such a mess of the original description -- that's what comes of writing and researching at the same time!
I experienced the same problem. As it impacts my network's security the medium priority/severity are an euphemism. Also since we're only dropping a patch, with clear explanation, why is this bug still open?
iptables-1.4.3.2-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/iptables-1.4.3.2-1.fc9
I take it this fix removes the nf_ext_init() patch? Has the same fix been submitted for Fedora 10 and Fedora 11?
iptables-1.4.3.2-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update iptables'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-5965
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.