Re: [PATCH v2 5/8] siteinfo: Move the rp-pppoe entry to common-linux

[Tom Rini <tom_rini@mentor.com>]

On 07/25/2011 09:55 AM, Tom Rini wrote:
> On 07/25/2011 09:40 AM, Phil Blundell wrote:
>> On Mon, 2011-07-25 at 09:00 -0700, Tom Rini wrote:
>>> On 07/25/2011 08:57 AM, Phil Blundell wrote:
>>>> On Fri, 2011-07-22 at 10:10 -0700, Tom Rini wrote:
>>>>> --- a/meta/site/common-linux
>>>>> +++ b/meta/site/common-linux
>>>>> @@ -23,3 +23,6 @@ bash_cv_unusable_rtsigs=${bash_cv_unusable_rtsigs=no}
>>>>>  # mysql
>>>>>  ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls=yes}
>>>>>  ac_cv_conv_longlong_to_float=${ac_cv_conv_longlong_to_float=yes}
>>>>> +
>>>>> +# rp-pppoe
>>>>> +rpppoe_cv_pack_bitfields=${rpppoe_cv_pack_bitfields=rev}
>>>>
>>>> Is that really correct?  Bitfield packing isn't an OS issue, it's
>>>> primarily a question of compiler choice.  For GCC I think it correlates
>>>> with endianness; looking at what that test is doing, I'd expect you to
>>>> get "reversed" on little-endian and "normal" on big-endian.
>>>
>>> It's possible we're getting this, and have been getting this wrong on
>>> big-endian targets but I haven't heard from Freescale this is failing
>>> for them.  I'm OK with dropping this bit out for now until we can
>>> confirm this test on a BE machine.
>>
>> That's probably best.  In any case, as far as I can tell rp-pppoe is
>> (despite what you might expect from the name) not actually in oe-core
>> itself, so perhaps its definitions don't belong in oe-core's site files
>> either.
> 
> Yeah.  At one point I was going to try and move the bits that oe-core
> doesn't use to meta-oe where they are or likely will be, but possibly
> after consolidation (and then just not adding in brand new ones, eg
> postgresql).

As you suspected, this is normal on BE and rev on LE.  I'll fix this for
meta-oe.

-- 
Tom Rini
Mentor Graphics Corporation