> On Dec 15, 2015, at 2:27 PM, Andre McCurdy <[email protected]> wrote: > > On Tue, Dec 15, 2015 at 12:43 PM, Khem Raj <[email protected]> wrote: >> >>> On Dec 15, 2015, at 12:16 PM, Paul Eggleton <[email protected]> >>> wrote: >>> >>> On Tue, 15 Dec 2015 12:07:48 Andre McCurdy wrote: >>>> On Tue, Dec 15, 2015 at 9:26 AM, Paul Eggleton >>>> >>>> <[email protected]> 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.
what problem do you foresee.? > 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. This patch here https://www.sourceware.org/ml/binutils/2013-11/msg00103.html tells me that armv7e should really be triggering on armv7a as well for all purposes > >>> Cheers, >>> Paul >>> >>> -- >>> >>> Paul Eggleton >>> Intel Open Source Technology Centre >>> -- >>> _______________________________________________ >>> Openembedded-core mailing list >>> [email protected] >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
