iptables is refusing to compile with linux-headers 2.6.6 and gcc 3.4. gcc -O2 -march=athlon64 -g3 -pipe -Iinclude -Wall -Wunused -I/usr/src/linux/include -DIPTABLES_VERSION=\"1.2.9\" -fPIC -o extensions/libipt_stealth_sh.o -c extensions/libipt_stealth.c In file included from include/libiptc/libiptc.h:6, from include/iptables.h:5, from extensions/libipt_stealth.c:10: /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: warning: no semicolon at end of struct or union /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:255: error: parse error before '*' token /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:259: error: parse error before '}' token /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: type defaults to `int' in declaration of `DECLARE_MUTEX' /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: parameter names (without types) in function declaration /usr/src/linux/include/linux/netfilter_ipv4/ip_tables.h:339: warning: 'DECLARE_MUTEX' declared `static' but never defined make: *** [extensions/libipt_stealth_sh.o] Error 1 !!! ERROR: net-firewall/iptables-1.2.9-r1 failed. !!! Function src_compile, Line 66, Exitcode 2 !!! (no error message)
<Lv> not yet, just re-assign it to me.... i have to figure out why it wont merge in stable but will in testing
i am a dumbass. i was using the 2.6.7-rc3 sources on my stable partition, but 2.6.7-rc2-mm2 on my testing partition. out of curiousity... why does iptables use /usr/src/linux and not linux-headers?
re-assigning to plasmaroo ^_^ *hides from pillow*
re-assigning to aliz at plasmaroo's suggestion. aliz - why doesnt iptables use the system headers? it seems like it would be more controllable that way, and the headers could be patched to allow iptables to always include the same extensions (grsec stuff?)
I've put a word in to Mariusz Mazur <mmazurXkernel.pl>, the maintainer of linux-headers package for 2.6. He replied to me and I've asked him to take a gander at it.
On poniedziałek, 14 czerwca 2004 17:56, David Ford wrote: >> To compile iptables 1.2.9. It seems that __user and DECLARE_MUTEX are >> missing. Please apply http://ep09.pld-linux.org/~mmazur/linux-libc-headers/patches/iptables.patch That patch will make iptables build against llh, not kernel headers.
Created attachment 33236 [details, diff] Changes iptables to use llh headers instead of linux kernel headers 1. add to files/1.2.9-files/ 2. bump to 1.2.9-r2 3. ebuild .. digest 4. emerge -u 5. admins rejoice
aliz was last seen 4 weeks, 5 days, 4 hours, 9 minutes and 57 seconds ago. re-assigning to bug-wranglers so that they can figure out where this goes...
I think the reason iptables builds against the linux sources is becuse it's easier to patch for the extensions that are applied to the iptables source. On one hand it's a good idea to have iptables built against "static" headers that are "under control". But on the other hand when new extensions are added iptables would have to depend on a new version of the linux headers that aren't updated/unmasked as frequent as iptables. So it all comes down to the extensions... I'm open for suggestions and ideas.
The maintainer of linux-headers for 2.6.x seems to be doing a pretty decent job of releasing often. I have to side with the LKML guys on this, userland applications should be using userland includes. If the headers are broken in this regard, then the headers should be fixed. Things change in /usr/src/linux far too much and that means a constant catch-up game. However, when things change that affect userland, then the changes should be propogated by the linux-headers package maintainer. As time progresses, the header mess that is exported from linux-source will get cleaned up naturally and extension oddities will become less frequent.
re-adding plasmaroo ^_^ plasmaroo - are you game for patching linux-headers for the extensions iptables supports, or should we just leave as is? what's your opinion? it should, perhaps, use an ALT_HEADERS variable like the new glibc... that way there is one default location for headers (/usr/include) that you can overwrite simply by setting an environment variable.
talked to plasmaroo on irc, he says drop it. dropping it.
As bug 54067 goes, there is already 1.2.10 out, anybody making applying the patch and putting that into portage tree for easier tesing. BTW, why is this marked as wontfix? From the discussion, I couldn't quite figure out what exctly the bug was.. I t was "cannot compile iptables with 2.6.x kernel", right? And the fix is to change ebuild to use linuh headers, right? So then this should be resolved-fixed, or I am wrong? And, Blu3, please don't add compressed patches here, or at least don't mark them as type "patch".
well, this bug WAS that iptables doesnt use system headers... but it seems that iptables doesnt compile using 2.6.7 at all and needs to optionally use system headers anyways.
iptables compiles fine on a 2.6.7-machine when you remove the /usr/src/linux symlink, so I guess it's just some INCDIR statement in the iptables sources...
For what it's worth, I'm using linux-headers 2.6.7 and iptables compiles without a problem when the /usr/src/linux symlink is removed but fails when the symlink points to my 2.6.7 kernel source files. The difference seems to be in include/linux/netfilter_ipv4/ip_tables.h, system headers have added the following lines which allow the compile. --- #ifndef DECLARE_MUTEX # include <asm/semaphore.h> #endif #include <linux/compiler.h> ---
<aliz> Lv: Regarding iptables being built against linux headers, Ive come up with a compromise. A new use flag that controls the applying of extension patches and building against the sources, otherwise iptables builds against the headers. i think that means this bug can be closed :)
I thing iptables compiles with /usr/src/linux because it is the only way to determine if a certain feature should be included at compile time or not. For example, if I don't select IMQ target in my kernel (CONFIG_IP_NF_TARGET_IMQ), libipt_IMQ.so will not be generated. Also, there are patches regarding iptables (patch-o-matic stuff) which modifies structures in kernel by appending new members to them, so you need to compile iptables with /usr/src/linux in order to work with your kernel, otherwise nasty things could happen. If the kernel headers installed by gentoo are generated based on my .config, then you could ignore my comment; else, it is best to let iptables using /usr/src/linux.
Travis. What's the new USE flag that will control this behaviour? Gus
the flag is called "extensions", as you can see if you launch "equery uses iptables" or "emerge -pv iptables"
