Re: iptables not building on master

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

On 12-03-06 10:24 AM, Khem Raj wrote:
> On 03/06/2012 07:21 AM, Robert Yang wrote:
>>
>>
>> On 03/06/2012 11:16 PM, Khem Raj wrote:
>>> On 03/06/2012 01:04 AM, Robert Yang wrote:
>>>>
>>>> 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.
>>>
>>> find out why iptables has its own copy of linux/types.h that file
>>> should be
>>> deleted if there is no reason to have it.
>>>
>>
>> Here is the reply from Bruce:
>>
>> 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.
>>
>
> it still does not say why iptables keeps a copy of its own.

Nominally it is to protect them from kernel headers changes and to not
require headers or a full tree to be present (or at least this is what
I've learned over the years, I may be forgetting other elements).

In the past, I've also removed this duplication of kernel header files
as well, and it does work, but it does create a tighter binding to
toolchain or kernel sources.

It is something that can be changed in the package, but as they say
"you end up with the pieces, if it breaks" :)

Cheers,

Bruce


> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto