[OE-core] [PATCH] valgrind: update to 3.11.0

Andre McCurdy armccurdy at gmail.com
Tue Dec 15 22:27:48 UTC 2015


On Tue, Dec 15, 2015 at 12:43 PM, Khem Raj <raj.khem at gmail.com> wrote:
>
>> On Dec 15, 2015, at 12:16 PM, Paul Eggleton <paul.eggleton at linux.intel.com> wrote:
>>
>> On Tue, 15 Dec 2015 12:07:48 Andre McCurdy wrote:
>>> On Tue, Dec 15, 2015 at 9:26 AM, Paul Eggleton
>>>
>>> <paul.eggleton at linux.intel.com> wrote:
>>>> On Tue, 15 Dec 2015 17:28:59 Alexander Kanavin wrote:
>>>>> On 12/15/2015 05:25 PM, Martin Jansa wrote:
>>>>>>> +COMPATIBLE_HOST = '(i.86|x86_64|mips|powerpc|powerpc64).*-linux'
>>>>>>> +COMPATIBLE_HOST_armv7a = 'arm.*-linux'
>>>>>>
>>>>>> Can you add armv7ve as well?
>>>>>
>>>>> Armv7ve support is not yet in master, so you'll have to add it later I'm
>>>>> afraid.
>>>>
>>>> I think by policy we don't have any restrictions on architecture-specific
>>>> flags in OE-Core (at least, assuming they're reasonable).
>>>
>>> If we're going to duplicate all _armv7a over-rides for _armv7ve then
>>> I'd vote to do so in a single patch series which fixes up the whole of
>>> oe-core rather than adding the over-rides one at a time amongst
>>> version updates etc.
>>
>> Makes sense, but before doing that would it make sense to have a grouping
>> override for all of them that can be used instead (where appropriate)?
>>
>
> stepping back a step. What so different about armv7ve that it needs to be a separate arch
> its just virtual extensions on top of armv7a, so any override pertaining to armv7a should
> be valid for it well. Can you work towards making it so ?

Trying to create a common over-ride for both might end up causing more
trouble in the long run. Perhaps it would instead make sense just to
try to remove some the _armv7a over-rides currently used in oe-core
(and meta-oe)? There aren't that many and some of them look a little
dubious or at least out of date and in need of a review.

For example for valgrind, we could blacklist armv4, armv5 and armv6
rather than whitelisting armv7a. The pixman recipe is assuming armv7a
is a reliable way to determine NEON support, which it isn't. The libav
recipes are using _armv7a to force some dubious looking optimisations.
Forcing the bfd linker in DirectFB doesn't need to be architecture
specific, etc. The only genuinely valid looking usage of the armv7a
over-ride seems to be gcc-configure-common.

>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



More information about the Openembedded-core mailing list