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 ? >> 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 >>> > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
