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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
