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

[Khem Raj]

On Wed, Jan 19, 2011 at 12:36 PM, Tom Rini <tom_rini at mentor.com> wrote:
> 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.

indeed, I just thought now that its using sane-toolchain but it included

conf/distro/include/${LIBC}.inc

before too so it was not broken

>
>> 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
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>