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
