iptables not building on master

iptables not building on master

[Autif Khan]

I was working with M2 until recently and had to switch to master.
After I switched to master, I tried to bitbake core-image-sato for
machine crownbay. The build fails with the following error:

unknown type name '__aligned_u64'

The file in question is extenstions/libxt_pkttypes.c

After a bit of investigation (thanks Khem) it seems like instead of
/usr/include/linux/types.h, the include/linux/types.h from iptables
source is being included. These a bit incompatible - specifically -
the definition for __aligned_u64 is not in the latter.

I am building core-image-sato for qemux86 and will report when the
build reaches that point.

Is this a known issue?

*** This issue should be hitting anyone doing a clean build on master.
Or at the very least someone who builds iptables recipe***

I looked at the recent change (post M2) that iptables was updated to
1.2.12.2 (from 1.2.12.1). There was a patch included for
extensions/GNUmakefile  which does not build "check" target. I looked
at what it does and realized that someone more experienced that I am
should look into this.

Thanks

Autif

Re: iptables not building on master

[Autif Khan]

I love working with master:

work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:

configure: error: Could not find pam/pam-devel, please install the
needed packages.

It seems like pam/pam-dev is needed in the target environment and not
in the host environment.

Although, iptables seem to have built. I can't imagine how it will be
affected by meta-intel and meta-crownbay - they do not do anything
with iptables.

Trying to build core-image-minimal for crownbay now. Will report when done.

On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan <autif.mlist@gmail.com> wrote:
> I was working with M2 until recently and had to switch to master.
> After I switched to master, I tried to bitbake core-image-sato for
> machine crownbay. The build fails with the following error:
>
> unknown type name '__aligned_u64'
>
> The file in question is extenstions/libxt_pkttypes.c
>
> After a bit of investigation (thanks Khem) it seems like instead of
> /usr/include/linux/types.h, the include/linux/types.h from iptables
> source is being included. These a bit incompatible - specifically -
> the definition for __aligned_u64 is not in the latter.
>
> I am building core-image-sato for qemux86 and will report when the
> build reaches that point.
>
> Is this a known issue?
>
> *** This issue should be hitting anyone doing a clean build on master.
> Or at the very least someone who builds iptables recipe***
>
> I looked at the recent change (post M2) that iptables was updated to
> 1.2.12.2 (from 1.2.12.1). There was a patch included for
> extensions/GNUmakefile  which does not build "check" target. I looked
> at what it does and realized that someone more experienced that I am
> should look into this.
>
> Thanks
>
> Autif

Re: iptables not building on master

[Autif Khan]

Interesting - core image minimal builds fine - it does not actually
build iptables. So the point is moot.

I did a clean build for core-image-sato and it failed at the same
place for the same error.

I am no sure how meta-intel + meta-crownbay can interact with iptables
- there is no recipe for iptables in meta-intel anywhere.

Tom - If you have the bandwidth - can you please see if you can
replicate my woes.

I do not know anyone else who is on master and crownbay. If there -
please let me know if things work for you.

This broke for me when I moved from M2 to master.

Thanks

Autif

On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan <autif.mlist@gmail.com> wrote:
> I love working with master:
>
> work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
>
> configure: error: Could not find pam/pam-devel, please install the
> needed packages.
>
> It seems like pam/pam-dev is needed in the target environment and not
> in the host environment.
>
> Although, iptables seem to have built. I can't imagine how it will be
> affected by meta-intel and meta-crownbay - they do not do anything
> with iptables.
>
> Trying to build core-image-minimal for crownbay now. Will report when done.
>
> On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan <autif.mlist@gmail.com> wrote:
>> I was working with M2 until recently and had to switch to master.
>> After I switched to master, I tried to bitbake core-image-sato for
>> machine crownbay. The build fails with the following error:
>>
>> unknown type name '__aligned_u64'
>>
>> The file in question is extenstions/libxt_pkttypes.c
>>
>> After a bit of investigation (thanks Khem) it seems like instead of
>> /usr/include/linux/types.h, the include/linux/types.h from iptables
>> source is being included. These a bit incompatible - specifically -
>> the definition for __aligned_u64 is not in the latter.
>>
>> I am building core-image-sato for qemux86 and will report when the
>> build reaches that point.
>>
>> Is this a known issue?
>>
>> *** This issue should be hitting anyone doing a clean build on master.
>> Or at the very least someone who builds iptables recipe***
>>
>> I looked at the recent change (post M2) that iptables was updated to
>> 1.2.12.2 (from 1.2.12.1). There was a patch included for
>> extensions/GNUmakefile  which does not build "check" target. I looked
>> at what it does and realized that someone more experienced that I am
>> should look into this.
>>
>> Thanks
>>
>> Autif

Re: iptables not building on master

[Tom Zanussi]

Hi Autif,

I'm sure it's nothing to do with crownbay or meta-intel, but I'll fire
off a build anyway.  I only have my laptop available, so it may take all
night, but will let you know what I find.  FWIW I normally build on
master of both meta-intel and poky and haven't seen this, so it must be
very recent.

Tom

On Mon, 2012-03-05 at 17:44 -0500, Autif Khan wrote:
> Interesting - core image minimal builds fine - it does not actually
> build iptables. So the point is moot.
> 
> I did a clean build for core-image-sato and it failed at the same
> place for the same error.
> 
> I am no sure how meta-intel + meta-crownbay can interact with iptables
> - there is no recipe for iptables in meta-intel anywhere.
> 
> Tom - If you have the bandwidth - can you please see if you can
> replicate my woes.
> 
> I do not know anyone else who is on master and crownbay. If there -
> please let me know if things work for you.
> 
> This broke for me when I moved from M2 to master.
> 
> Thanks
> 
> Autif
> 
> On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan <autif.mlist@gmail.com> wrote:
> > I love working with master:
> >
> > work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
> >
> > configure: error: Could not find pam/pam-devel, please install the
> > needed packages.
> >
> > It seems like pam/pam-dev is needed in the target environment and not
> > in the host environment.
> >
> > Although, iptables seem to have built. I can't imagine how it will be
> > affected by meta-intel and meta-crownbay - they do not do anything
> > with iptables.
> >
> > Trying to build core-image-minimal for crownbay now. Will report when done.
> >
> > On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan <autif.mlist@gmail.com> wrote:
> >> I was working with M2 until recently and had to switch to master.
> >> After I switched to master, I tried to bitbake core-image-sato for
> >> machine crownbay. The build fails with the following error:
> >>
> >> unknown type name '__aligned_u64'
> >>
> >> The file in question is extenstions/libxt_pkttypes.c
> >>
> >> After a bit of investigation (thanks Khem) it seems like instead of
> >> /usr/include/linux/types.h, the include/linux/types.h from iptables
> >> source is being included. These a bit incompatible - specifically -
> >> the definition for __aligned_u64 is not in the latter.
> >>
> >> I am building core-image-sato for qemux86 and will report when the
> >> build reaches that point.
> >>
> >> Is this a known issue?
> >>
> >> *** This issue should be hitting anyone doing a clean build on master.
> >> Or at the very least someone who builds iptables recipe***
> >>
> >> I looked at the recent change (post M2) that iptables was updated to
> >> 1.2.12.2 (from 1.2.12.1). There was a patch included for
> >> extensions/GNUmakefile  which does not build "check" target. I looked
> >> at what it does and realized that someone more experienced that I am
> >> should look into this.
> >>
> >> Thanks
> >>
> >> Autif

Re: iptables not building on master

[Cui, Dexuan]

Hi all, I got the same issue 3 days age and reported a bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2053

I did some analysis and I tend to think we need to fix iptables's makefile.
I have been in a business traval since then so I can't continue the debugging.
It would be great if somebody can help on this.

Thanks,
-- Dexuan


> -----Original Message-----
> From: yocto-bounces@yoctoproject.org
> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tom Zanussi
> Sent: Tuesday, March 06, 2012 1:10 PM
> To: Autif Khan
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] iptables not building on master
> 
> Hi Autif,
> 
> I'm sure it's nothing to do with crownbay or meta-intel, but I'll fire off a
> build anyway.  I only have my laptop available, so it may take all night,
> but will let you know what I find.  FWIW I normally build on master of
> both meta-intel and poky and haven't seen this, so it must be very recent.
> 
> Tom
> 
> On Mon, 2012-03-05 at 17:44 -0500, Autif Khan wrote:
> > Interesting - core image minimal builds fine - it does not actually
> > build iptables. So the point is moot.
> >
> > I did a clean build for core-image-sato and it failed at the same
> > place for the same error.
> >
> > I am no sure how meta-intel + meta-crownbay can interact with iptables
> > - there is no recipe for iptables in meta-intel anywhere.
> >
> > Tom - If you have the bandwidth - can you please see if you can
> > replicate my woes.
> >
> > I do not know anyone else who is on master and crownbay. If there -
> > please let me know if things work for you.
> >
> > This broke for me when I moved from M2 to master.
> >
> > Thanks
> >
> > Autif
> >
> > On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan <autif.mlist@gmail.com>
> wrote:
> > > I love working with master:
> > >
> > > work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
> > >
> > > configure: error: Could not find pam/pam-devel, please install the
> > > needed packages.
> > >
> > > It seems like pam/pam-dev is needed in the target environment and
> > > not in the host environment.
> > >
> > > Although, iptables seem to have built. I can't imagine how it will
> > > be affected by meta-intel and meta-crownbay - they do not do
> > > anything with iptables.
> > >
> > > Trying to build core-image-minimal for crownbay now. Will report
> when done.
> > >
> > > On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan <autif.mlist@gmail.com>
> wrote:
> > >> I was working with M2 until recently and had to switch to master.
> > >> After I switched to master, I tried to bitbake core-image-sato for
> > >> machine crownbay. The build fails with the following error:
> > >>
> > >> unknown type name '__aligned_u64'
> > >>
> > >> The file in question is extenstions/libxt_pkttypes.c
> > >>
> > >> After a bit of investigation (thanks Khem) it seems like instead of
> > >> /usr/include/linux/types.h, the include/linux/types.h from iptables
> > >> source is being included. These a bit incompatible - specifically -
> > >> the definition for __aligned_u64 is not in the latter.
> > >>
> > >> I am building core-image-sato for qemux86 and will report when the
> > >> build reaches that point.
> > >>
> > >> Is this a known issue?
> > >>
> > >> *** This issue should be hitting anyone doing a clean build on
> master.
> > >> Or at the very least someone who builds iptables recipe***
> > >>
> > >> I looked at the recent change (post M2) that iptables was updated
> > >> to
> > >> 1.2.12.2 (from 1.2.12.1). There was a patch included for
> > >> extensions/GNUmakefile  which does not build "check" target. I
> > >> looked at what it does and realized that someone more experienced
> > >> that I am should look into this.
> > >>
> > >> Thanks
> > >>
> > >> Autif
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: iptables not building on master

[Robert Yang]

Hi Dexuan,

I will take the bug and work on it.

// Robert

On 03/06/2012 01:35 PM, Cui, Dexuan wrote:
> Hi all, I got the same issue 3 days age and reported a bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2053
>
> I did some analysis and I tend to think we need to fix iptables's makefile.
> I have been in a business traval since then so I can't continue the debugging.
> It would be great if somebody can help on this.
>
> Thanks,
> -- Dexuan
>
>
>> -----Original Message-----
>> From: yocto-bounces@yoctoproject.org
>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tom Zanussi
>> Sent: Tuesday, March 06, 2012 1:10 PM
>> To: Autif Khan
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] iptables not building on master
>>
>> Hi Autif,
>>
>> I'm sure it's nothing to do with crownbay or meta-intel, but I'll fire off a
>> build anyway.  I only have my laptop available, so it may take all night,
>> but will let you know what I find.  FWIW I normally build on master of
>> both meta-intel and poky and haven't seen this, so it must be very recent.
>>
>> Tom
>>
>> On Mon, 2012-03-05 at 17:44 -0500, Autif Khan wrote:
>>> Interesting - core image minimal builds fine - it does not actually
>>> build iptables. So the point is moot.
>>>
>>> I did a clean build for core-image-sato and it failed at the same
>>> place for the same error.
>>>
>>> I am no sure how meta-intel + meta-crownbay can interact with iptables
>>> - there is no recipe for iptables in meta-intel anywhere.
>>>
>>> Tom - If you have the bandwidth - can you please see if you can
>>> replicate my woes.
>>>
>>> I do not know anyone else who is on master and crownbay. If there -
>>> please let me know if things work for you.
>>>
>>> This broke for me when I moved from M2 to master.
>>>
>>> Thanks
>>>
>>> Autif
>>>
>>> On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan<autif.mlist@gmail.com>
>> wrote:
>>>> I love working with master:
>>>>
>>>> work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
>>>>
>>>> configure: error: Could not find pam/pam-devel, please install the
>>>> needed packages.
>>>>
>>>> It seems like pam/pam-dev is needed in the target environment and
>>>> not in the host environment.
>>>>
>>>> Although, iptables seem to have built. I can't imagine how it will
>>>> be affected by meta-intel and meta-crownbay - they do not do
>>>> anything with iptables.
>>>>
>>>> Trying to build core-image-minimal for crownbay now. Will report
>> when done.
>>>>
>>>> On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan<autif.mlist@gmail.com>
>> wrote:
>>>>> I was working with M2 until recently and had to switch to master.
>>>>> After I switched to master, I tried to bitbake core-image-sato for
>>>>> machine crownbay. The build fails with the following error:
>>>>>
>>>>> unknown type name '__aligned_u64'
>>>>>
>>>>> The file in question is extenstions/libxt_pkttypes.c
>>>>>
>>>>> After a bit of investigation (thanks Khem) it seems like instead of
>>>>> /usr/include/linux/types.h, the include/linux/types.h from iptables
>>>>> source is being included. These a bit incompatible - specifically -
>>>>> the definition for __aligned_u64 is not in the latter.
>>>>>
>>>>> I am building core-image-sato for qemux86 and will report when the
>>>>> build reaches that point.
>>>>>
>>>>> Is this a known issue?
>>>>>
>>>>> *** This issue should be hitting anyone doing a clean build on
>> master.
>>>>> Or at the very least someone who builds iptables recipe***
>>>>>
>>>>> I looked at the recent change (post M2) that iptables was updated
>>>>> to
>>>>> 1.2.12.2 (from 1.2.12.1). There was a patch included for
>>>>> extensions/GNUmakefile  which does not build "check" target. I
>>>>> looked at what it does and realized that someone more experienced
>>>>> that I am should look into this.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Autif
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: iptables not building on master

[Tom Zanussi]

In the meantime, if you remove the line:

PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

from meta-intel/conf/machine/include/ia32-base.inc

it will pick up the same headers as qemux86 and you shouldn't see this
problem.

Tom 

On Tue, 2012-03-06 at 13:59 +0800, Robert Yang wrote:
> Hi Dexuan,
> 
> I will take the bug and work on it.
> 
> // Robert
> 
> On 03/06/2012 01:35 PM, Cui, Dexuan wrote:
> > Hi all, I got the same issue 3 days age and reported a bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2053
> >
> > I did some analysis and I tend to think we need to fix iptables's makefile.
> > I have been in a business traval since then so I can't continue the debugging.
> > It would be great if somebody can help on this.
> >
> > Thanks,
> > -- Dexuan
> >
> >
> >> -----Original Message-----
> >> From: yocto-bounces@yoctoproject.org
> >> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tom Zanussi
> >> Sent: Tuesday, March 06, 2012 1:10 PM
> >> To: Autif Khan
> >> Cc: yocto@yoctoproject.org
> >> Subject: Re: [yocto] iptables not building on master
> >>
> >> Hi Autif,
> >>
> >> I'm sure it's nothing to do with crownbay or meta-intel, but I'll fire off a
> >> build anyway.  I only have my laptop available, so it may take all night,
> >> but will let you know what I find.  FWIW I normally build on master of
> >> both meta-intel and poky and haven't seen this, so it must be very recent.
> >>
> >> Tom
> >>
> >> On Mon, 2012-03-05 at 17:44 -0500, Autif Khan wrote:
> >>> Interesting - core image minimal builds fine - it does not actually
> >>> build iptables. So the point is moot.
> >>>
> >>> I did a clean build for core-image-sato and it failed at the same
> >>> place for the same error.
> >>>
> >>> I am no sure how meta-intel + meta-crownbay can interact with iptables
> >>> - there is no recipe for iptables in meta-intel anywhere.
> >>>
> >>> Tom - If you have the bandwidth - can you please see if you can
> >>> replicate my woes.
> >>>
> >>> I do not know anyone else who is on master and crownbay. If there -
> >>> please let me know if things work for you.
> >>>
> >>> This broke for me when I moved from M2 to master.
> >>>
> >>> Thanks
> >>>
> >>> Autif
> >>>
> >>> On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan<autif.mlist@gmail.com>
> >> wrote:
> >>>> I love working with master:
> >>>>
> >>>> work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
> >>>>
> >>>> configure: error: Could not find pam/pam-devel, please install the
> >>>> needed packages.
> >>>>
> >>>> It seems like pam/pam-dev is needed in the target environment and
> >>>> not in the host environment.
> >>>>
> >>>> Although, iptables seem to have built. I can't imagine how it will
> >>>> be affected by meta-intel and meta-crownbay - they do not do
> >>>> anything with iptables.
> >>>>
> >>>> Trying to build core-image-minimal for crownbay now. Will report
> >> when done.
> >>>>
> >>>> On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan<autif.mlist@gmail.com>
> >> wrote:
> >>>>> I was working with M2 until recently and had to switch to master.
> >>>>> After I switched to master, I tried to bitbake core-image-sato for
> >>>>> machine crownbay. The build fails with the following error:
> >>>>>
> >>>>> unknown type name '__aligned_u64'
> >>>>>
> >>>>> The file in question is extenstions/libxt_pkttypes.c
> >>>>>
> >>>>> After a bit of investigation (thanks Khem) it seems like instead of
> >>>>> /usr/include/linux/types.h, the include/linux/types.h from iptables
> >>>>> source is being included. These a bit incompatible - specifically -
> >>>>> the definition for __aligned_u64 is not in the latter.
> >>>>>
> >>>>> I am building core-image-sato for qemux86 and will report when the
> >>>>> build reaches that point.
> >>>>>
> >>>>> Is this a known issue?
> >>>>>
> >>>>> *** This issue should be hitting anyone doing a clean build on
> >> master.
> >>>>> Or at the very least someone who builds iptables recipe***
> >>>>>
> >>>>> I looked at the recent change (post M2) that iptables was updated
> >>>>> to
> >>>>> 1.2.12.2 (from 1.2.12.1). There was a patch included for
> >>>>> extensions/GNUmakefile  which does not build "check" target. I
> >>>>> looked at what it does and realized that someone more experienced
> >>>>> that I am should look into this.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Autif
> >>
> >>
> >> _______________________________________________
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >

Re: iptables not building on master

[Robert Yang]

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.

I will send a pull request after enough testing.

// Robert

On 03/06/2012 02:48 PM, Tom Zanussi wrote:
> In the meantime, if you remove the line:
>
> PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
>
> from meta-intel/conf/machine/include/ia32-base.inc
>
> it will pick up the same headers as qemux86 and you shouldn't see this
> problem.
>
> Tom
>
> On Tue, 2012-03-06 at 13:59 +0800, Robert Yang wrote:
>> Hi Dexuan,
>>
>> I will take the bug and work on it.
>>
>> // Robert
>>
>> On 03/06/2012 01:35 PM, Cui, Dexuan wrote:
>>> Hi all, I got the same issue 3 days age and reported a bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=2053
>>>
>>> I did some analysis and I tend to think we need to fix iptables's makefile.
>>> I have been in a business traval since then so I can't continue the debugging.
>>> It would be great if somebody can help on this.
>>>
>>> Thanks,
>>> -- Dexuan
>>>
>>>
>>>> -----Original Message-----
>>>> From: yocto-bounces@yoctoproject.org
>>>> [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Tom Zanussi
>>>> Sent: Tuesday, March 06, 2012 1:10 PM
>>>> To: Autif Khan
>>>> Cc: yocto@yoctoproject.org
>>>> Subject: Re: [yocto] iptables not building on master
>>>>
>>>> Hi Autif,
>>>>
>>>> I'm sure it's nothing to do with crownbay or meta-intel, but I'll fire off a
>>>> build anyway.  I only have my laptop available, so it may take all night,
>>>> but will let you know what I find.  FWIW I normally build on master of
>>>> both meta-intel and poky and haven't seen this, so it must be very recent.
>>>>
>>>> Tom
>>>>
>>>> On Mon, 2012-03-05 at 17:44 -0500, Autif Khan wrote:
>>>>> Interesting - core image minimal builds fine - it does not actually
>>>>> build iptables. So the point is moot.
>>>>>
>>>>> I did a clean build for core-image-sato and it failed at the same
>>>>> place for the same error.
>>>>>
>>>>> I am no sure how meta-intel + meta-crownbay can interact with iptables
>>>>> - there is no recipe for iptables in meta-intel anywhere.
>>>>>
>>>>> Tom - If you have the bandwidth - can you please see if you can
>>>>> replicate my woes.
>>>>>
>>>>> I do not know anyone else who is on master and crownbay. If there -
>>>>> please let me know if things work for you.
>>>>>
>>>>> This broke for me when I moved from M2 to master.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Autif
>>>>>
>>>>> On Mon, Mar 5, 2012 at 4:27 PM, Autif Khan<autif.mlist@gmail.com>
>>>> wrote:
>>>>>> I love working with master:
>>>>>>
>>>>>> work/i586-poky-linux/polkit-0.104-r4/temp/log.do_configure says:
>>>>>>
>>>>>> configure: error: Could not find pam/pam-devel, please install the
>>>>>> needed packages.
>>>>>>
>>>>>> It seems like pam/pam-dev is needed in the target environment and
>>>>>> not in the host environment.
>>>>>>
>>>>>> Although, iptables seem to have built. I can't imagine how it will
>>>>>> be affected by meta-intel and meta-crownbay - they do not do
>>>>>> anything with iptables.
>>>>>>
>>>>>> Trying to build core-image-minimal for crownbay now. Will report
>>>> when done.
>>>>>>
>>>>>> On Mon, Mar 5, 2012 at 4:03 PM, Autif Khan<autif.mlist@gmail.com>
>>>> wrote:
>>>>>>> I was working with M2 until recently and had to switch to master.
>>>>>>> After I switched to master, I tried to bitbake core-image-sato for
>>>>>>> machine crownbay. The build fails with the following error:
>>>>>>>
>>>>>>> unknown type name '__aligned_u64'
>>>>>>>
>>>>>>> The file in question is extenstions/libxt_pkttypes.c
>>>>>>>
>>>>>>> After a bit of investigation (thanks Khem) it seems like instead of
>>>>>>> /usr/include/linux/types.h, the include/linux/types.h from iptables
>>>>>>> source is being included. These a bit incompatible - specifically -
>>>>>>> the definition for __aligned_u64 is not in the latter.
>>>>>>>
>>>>>>> I am building core-image-sato for qemux86 and will report when the
>>>>>>> build reaches that point.
>>>>>>>
>>>>>>> Is this a known issue?
>>>>>>>
>>>>>>> *** This issue should be hitting anyone doing a clean build on
>>>> master.
>>>>>>> Or at the very least someone who builds iptables recipe***
>>>>>>>
>>>>>>> I looked at the recent change (post M2) that iptables was updated
>>>>>>> to
>>>>>>> 1.2.12.2 (from 1.2.12.1). There was a patch included for
>>>>>>> extensions/GNUmakefile  which does not build "check" target. I
>>>>>>> looked at what it does and realized that someone more experienced
>>>>>>> that I am should look into this.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Autif
>>>>
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>
>
>

Re: iptables not building on master

[Cui, Dexuan]

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

Re: iptables not building on master

[Robert Yang]

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.
>

Yes, you are right:-)

> 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.
>

Yes, I agree with you ,I was going to change the older of the header files
at first, but after thought for a while, I don't know why iptables carries
part of the kernel header files, I don't know whether change the order of
the headers would cause other problems. I checked the linux/if_packet.h when
MACHINE=qemux86, it is different from the crownbay's, it doesn't have the
__aligned_u64, so I choose the simple and impact less way to fix it:-)

Anyway, if you insist on changing the order, I will try to do it.

// Robert

>
> Thanks,
> -- Dexuan
>
>

Re: iptables not building on master

[Robert Yang]

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
>
>

Re: iptables not building on master

[Koen Kooi]

Op 6 mrt. 2012, om 07:48 heeft Tom Zanussi het volgende geschreven:

> In the meantime, if you remove the line:
> 
> PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"

Why is a BSP layer poking at DISTRO settings?!?!?![1]

koen

[1] Yes RP, that really needed that many exclamation marks :)

Re: iptables not building on master

[Bruce Ashfield]

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

Re: iptables not building on master

[Khem Raj]

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.

>
> 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.
>
> I will send a pull request after enough testing.

> https://lists.yoctoproject.org/listinfo/yocto

Re: iptables not building on master

[Robert Yang]

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.

// Robert

>>
>> 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.
>>
>> I will send a pull request after enough testing.
>
>> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: iptables not building on master

[Khem Raj]

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.

Re: iptables not building on master

[Bruce Ashfield]

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

Re: iptables not building on master

[Tom Zanussi]

On Tue, 2012-03-06 at 13:14 +0100, Koen Kooi wrote:
> Op 6 mrt. 2012, om 07:48 heeft Tom Zanussi het volgende geschreven:
> 
> > In the meantime, if you remove the line:
> > 
> > PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc-headers-yocto"
> 
> Why is a BSP layer poking at DISTRO settings?!?!?![1]

Yes, you're right - I've been carrying a patch to remove this as part of
my current BSP work, but hadn't posted it yet.  Just now did though...

Tom  

> 
> koen
> 
> [1] Yes RP, that really needed that many exclamation marks :)

Re: iptables not building on master

[Khem Raj]

On Tue, Mar 6, 2012 at 7:27 AM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> 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).
>

but thats what linux-kernel-headers are now a days isnt it ?

> 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.

from OE's POV we can assume that we will always have kernel-headers
so we could prefer them instead ? We are not interested in building it
standalone but rather with some distro

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

Re: iptables not building on master

[Bruce Ashfield]

On 12-03-06 12:28 PM, Khem Raj wrote:
> On Tue, Mar 6, 2012 at 7:27 AM, Bruce Ashfield
> <bruce.ashfield@windriver.com>  wrote:
>> 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).
>>
>
> but thats what linux-kernel-headers are now a days isnt it ?

It definitely is, this probably falls into "if it works .. " so
it stays as-is.

>
>> 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.
>
> from OE's POV we can assume that we will always have kernel-headers
> so we could prefer them instead ? We are not interested in building it
> standalone but rather with some distro
>

Agreed.

Bruce


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