[oe] [PATCH 1/2] minimal.conf: Prefer perl 5.10.1 and opie 1.2.5

[Tom Rini]

On 01/19/2011 10:57 AM, Khem Raj wrote:
> On Wed, Jan 19, 2011 at 9:37 AM, Tom Rini<tom_rini at mentor.com>  wrote:
>> On 01/18/2011 09:29 PM, Khem Raj wrote:
>>>
>>> On (18/01/11 20:59), Tom Rini wrote:
>>>>
>>>> On 01/17/2011 09:30 PM, Roman I Khimov wrote:
>>>>>
>>>>> В сообщении от Понедельник 17 января 2011 22:14:51 автор Tom Rini
>>>>> написал:
>>>>>>
>>>>>> On 01/17/2011 10:50 AM, Khem Raj wrote:
>>>>>> I see different problems with perl 5.10.1 + uclibc + p2020ds, so I
>>>>>> guess
>>>>>> this is fine with me.
>>>>>
>>>>> What kind of problems?
>>>>
>>>> Khem fixed it tonight.  At heart, there's been a need to make much
>>>> better use of the libc-uclibc override rather than testing TARGET_OS
>>>> as there's at least 'linux-uclibc', 'linux-uclibceabi' and
>>>> 'linux-uclibcspe' as valid TARGET_OS combinations.
>>>
>>> I thought about it and indeed it would be better to have a LIBC override
>>> but its defined in .inc files which may not be included by all
>>> distributions, if this makes into bitbake.conf somehow then that would
>>> be better or we can decide to have a global data var called LIBC or some
>>> sort.
>>
>> We already did this.  A distro that doesn't pull in the right libc inc file
>> is either broken or on its own (I forget and can't check atm if Angstrom
>> uses the files eventually or just also has the libc-foo OVERRIDES, but is
>> correct here).
>
> yes angstrom does. Ok I moved slugos to use it recently so its no more broken :)

Um, when did SlugOS break then?  When I introduced the libc overrides I 
moved everyone over to it.

> We also have LIBC as a global env way to say what LIBC to
>> use (Angstrom has ANGSTROMLIBC and LIBC since they originated the feature).
>
> nice we can use LIBC as well if need be but override is more elegant

Yes, LIBC shouldn't be parsed like that, it's like MACHINE :)

-- 
Tom Rini
Mentor Graphics Corporation