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.

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

Reply via email to