> On Dec 15, 2015, at 7:11 PM, Andre McCurdy <[email protected]> wrote: > > On Tue, Dec 15, 2015 at 5:50 PM, Khem Raj <[email protected]> wrote: >> >>> 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.? > > Just the potential for confusion really. Also wondering what will > happen if/when people start to seriously use armv7r and armv7m. Should > they also try to share an over-ride with armv7a ?
‘r' and ‘m’ are different at ISA level not the case with ‘ve' > >>> 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
