Re: iptables: compiling with kernel headers

[Phil Sutter <phil@nwl.cc>]

On Thu, Aug 08, 2024 at 11:08:09AM +0000, Joshua Lant wrote:
> Hi Phil,
> 
> > > When I try to compile iptables using —with-kernel, or —with-ksource, I
> > > get this error:
> > > 
> > > In file included from …/iptables-morello/extensions/libxt_TOS.c:16:
> > > In file included from …/iptables-morello/extensions/tos_values.c:4:
> > > In file included from …/kernel-source/include/uapi/linux/ip.h:22:
> > > In file included from
> > > …/usr/src/linux-headers-morello/include/asm/byteorder.h:23:
> > > In file included from
> > > …/kernel-source/include/uapi/linux/byteorder/little_endian.h:14:
> > > …/kernel-source/include/uapi/linux/swab.h:48:15: error: unknown type
> > > name '__attribute_const__'
> > 
> > I can't reproduce this here.
> >
> > > I see that this error arises because when I set the —with-kernel flag
> > > libxt_TOS.c is being compiled against ./include/uapi/linux/ip.h. But
> > > when I compile without that flag, the -isystem flag value provides the
> > > ./include/linux/ip.h.
> > 
> > What './include/linux/ip.h' is that? It's not in iptables.git. On my
> > system, /usr/include/linux/ip.h is basically identical to
> > include/uapi/linux/ip.h in my clone of linux.git.
> > 
> 
> Both the ip.h are under the linux git clone, one in
> <repo>/include/linux/ip.h and one in <repo>/include/uapi/linux/ip.h. I
> am setting the --with-kernel or --with-ksource to be the root of the
> linux git repo.

Ah! Well, include/linux/ip.h includes uapi/linux/ip.h so they are not
entirely incompatible. User space might choke on the former's extras,
though.

> > Did you retry using gcc? I personally don't use --with-kernel/ksource,
> > so from my very own perspective, this feature is unused and untested. ;)
> > 
> 
> GCC is not an option really. My whole build system is set up around
> clang, and the status of the morello GCC compiler is not as mature I
> don't think, so could cause more issues than it solves...

I assumed you see the problem with --with-kernel with x86_64, too.

> > These are bugs IMO. Kernel headers are supposed to be compatible, so one
> > should not have to adjust user space for newer headers - the problem
> > with xt_connmark.h is an exception to the rule in my perspective.
> > 
> ... 
> > If it helps you, feel free to submit a patch updating the cached
> > xt_connmark.h and dropping said enum from libxt_CONNMARK.c. Same for
> > other issues you noticed. In doubt just send me a report and I'll see
> > how I can resolve things myself.
> > 
> 
> Okay, I'll start trying to update the headers and see how far I get through
> the compilation. Thanks a lot for your input.

YW!

Cheers, Phil