Re: iptables not building on master

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 12-03-06 06:41 AM, Robert Yang wrote:
>
> Hi Dexuan,
>
> After more investigation, I found that the:
>
> -I/path/to/sysroot/usr/include
>
> has been treated as the standard system include directory,
>
> and from gcc's manual:
>
> -I dir
> Add the directory dir to the list of directories to be searched for
> header files. Directories named by -I are searched
> before the standard system include directories. If the directory dir is
> a standard system include directory, the option is
> ignored to ensure that the default search order for system directories
> and the special treatment of system headers are not
> defeated .
>
>
> so whether we put the kinclude_CPPFLAGS at the front or end doesn't
> change the search order, gcc will always search iptables-1.4.12.2/include/
> firstly, if we want to use the those header files consistently from the
> sysroot, we should remove the iptables-1.4.12.2/include/linux directly
> since all the files in this directory are from kernel headers, but after
> I remove the directory, the build failed at:
>
> | In file included from libip4tc.c:118:0:
> | libiptc.c:70:8: error: redefinition of 'struct xt_error_target'
> |
> /buildarea/lyang1/war_8/tmp/sysroots/crownbay/usr/include/linux/netfilter/x_tables.h:69:8:
> note: originally defined here
>
> It seems that iptables keep and use their own kernel header files.

iptables has always done this .. and it has periodically caused issues like
this in the past. Typically something like you have above is done, or
iptables is updated to a newer version (I assume we can't do that
in this case?), to fix any build issues.

I've had iptables in a directory/location with a dependency on a particular
kernel version (to show the coupling) in the past to enforce a check
before the build breaks.

Cheers,

Bruce

>
> I will send a pull request with the fix method:
>
> #define __aligned_u64 __u64 __attribute__((aligned(8)))
>
> // Robert
>
> On 03/06/2012 05:47 PM, Cui, Dexuan wrote:
>> Robert Yang wrote on 2012-03-06:
>>> Hi Tom,
>>> Thanks for the update, the root cause is that iptables offers a kernel
>>> header file include/linux/types.h, but it mis-matches the kernel in
>>> the sysroot, we can add this:
>>> #define __aligned_u64 __u64 __attribute__((aligned(8)))
>>> to:
>>> iptables-1.4.12.2/include/linux/types.h
>>> to fix this problem.
>>>
>>> Another solution is that as Dexuan suggested we change the order of
>>> the include header files, but I'm afraid that may cause other
>>> problems, since I think that the pkg's own header file should have a
>>> higher priority than the system's, so I think that the current order
>>> is correct.
>> My understanding is:
>> Recently the preferred linux-libc-headers was upgraded to
>> linux-libc-headers-yocto-3.2, that introduced a new struct
>> tpacket_hdr_v1 in linux/if_packet.h and the new struct uses
>> __aligned_u64 but __aligned_u64 is not defined in iptables's own
>> linux/types.h
>> Currently in iptables's makefile, its own linux/types.h comes first
>> than that one in our sysroot in the header file search order, and I
>> noticed iptables doesn't have a file linux/if_packet.h. So, with our
>> sysroot's linux/if_package.h and iptables's own linux/types, we get
>> the failure.
>>
>> If we define __aligned_u64 _ in iptables's own linux/types.h, we're
>> still using our sysroot's linux/if_packet.h with iptables's
>> linux/types.h -- I think this is not correct even if the build can
>> pass? I think we should use header files consistently.
>>
>>
>> Thanks,
>> -- Dexuan
>>
>>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto