On Monday 2018-06-25 04:51, Duncan Roe wrote: >ebtables carries a private copy of some system headers provided by the >kernel-headers package. These were mostly still being included with angle >brackets as though they were in the /usr/include tree. Normally-configuerd gcc >picks up the local header in these cases. No it does not! >With [...] https://bitbucket.org/kille72/freshtomato-arm >The freshtomato developers have been taking ebtables snapshots and patching >those #include statements that actually fail. This results in some system >headers being included in lieu of local copies so this patch fixes all #include >statements. I analyzed that project, and found that the so-essential "-Iinclude/" that is present on a native build is substituted by "-I/home/linux/ftm/release/$MORESUBDIRS/linux-2.6.36/include". That is completely _wrong_: - the ebtables shipped header copies go totally unused - the unsanitized variant of the kernel headers are used; "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders" is printed for every gcc invocation moreover, - kernel headers are out of date (just look at it! 2.6.36!) That's why ebtables ships recent copies in the first place... doesn't help much if they never get used. Your patch is therefore also not the right approach. freshtomato must not override KERNEL_INCLUDES. Yes, ebtables's Makefile invites one to do so. ebtables's Makefile is wrong to suggest so. >This is an active project with 2 commits in the last 24hrs ATOW. But the history also shows a 6-year-gap between updating iptables. ebtables was updated in FTM to 2.0.10.4 on Mar 5 2015. On Feb 27 2015 already, ebtables.git received shipped headers because a user ran into the same issue with using /usr/include beforehand. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html