Andrew Benton wrote: > Andrew Benton wrote: >> Uh-oh, it's that time again. New kernel headers, new breakage. It seems >> that iptables has issues with the new kernel headers. Anybody else >> seeing this? >> >> cc -O2 -Wall -Wunused -I/usr/src/linux/include -Iinclude/ >> -DIPTABLES_VERSION=\"1.3.1\" -D_UNKNOWN_KERNEL_POINTER_SIZE -fPIC -o >> extensions/libipt_CONNMARK_sh.o -c extensions/libipt_CONNMARK.c >> ld -shared -o extensions/libipt_CONNMARK.so >> extensions/libipt_CONNMARK_sh.o >> cc -O2 -Wall -Wunused -I/usr/src/linux/include -Iinclude/ >> -DIPTABLES_VERSION=\"1.3.1\" -D_UNKNOWN_KERNEL_POINTER_SIZE -fPIC -o >> extensions/libipt_DNAT_sh.o -c extensions/libipt_DNAT.c >> extensions/libipt_DNAT.c:16: error: field `mr' has incomplete type >> extensions/libipt_DNAT.c:228: error: invalid application of `sizeof' to >> incomplete type `ip_nat_multi_range_compat' >> extensions/libipt_DNAT.c:229: error: invalid application of `sizeof' to >> incomplete type `ip_nat_multi_range_compat' >> make: *** [extensions/libipt_DNAT_sh.o] Error 1 > Well, just to answer myself, I took the dirty route and untarred the > kernel sources in /usr/src/linux and now it builds fine. User space > applications shouldn't need to build against the raw kernel sources. Does > anyone know a cleaner solution?
Well a sollution is to make a directory /usr/src/linux/include, which is a real directory, not a symlink to somewhere. Now put in here the symbolic links asm and linux which are pointing to /usr/linux/include/asm and /usr/linux/include/linux (in that order). (these links are pointing to an absolute path, of course you can use relative paths instead) Now compilation goes fine. And never let this directory /usr/src/linux point to anywhere else. Stef Bon -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
