Fix Arm detection improvements

[nullr0ute]

There's some issues with the detection of particular Arm hardware
features. We never want to use the crypto feature as part of rpm
functionality, it's deployment is widely variable, and the HW
optimisation should be run time detected with fall back through
various optimisation paths.

The 8c3a7b8 commit where this functionality also has other issues
it didn't include the VFP HWCAP for armv6 which rpm included
previously, but just the VFP3, and NEON is a requirement, and hence
always present in armv8 so it's assumed that it's part of armv8.

Signed-off-by: Peter Robinson pbrobinson@gmail.com

[pmatilai]

Fixing a fix of a fix is always a bit of a red flag.

The unification in commit 8c3a7b8 assumes that we'll want to keep adding these modifier letters like 'h' forever more for all new versions to come, but isn't VFP/VFPv3 capability a requirement in >= armv8 already?

In other words, was the unification the right thing to do at all? Should we instead revert it and then if there was something to fix and add, do that in separate individual steps?

[nullr0ute]

Possibly a straight up revert is the right thing to do. I was trying to keep the intention of the previous patch as much as possible.

In terms of VFP/VFPv3 it is a requirement of ARMv8, but in theory (although I'm not sure why you'd want to) you could have softfp builds on armv8 so to keep compatibility with armv[567]l (softfp) vs armv[678]hl (hardfp) I think you'd want to to keep those the same as a designator. For NEON it's a requirement on armv8 so I think that would just be built if building armv8XX.

[Conan-Kudo]

cc: @berolinux

[pmatilai]

This got stalled ages ago, and in the meanwhile the Arm stuff has been reverted, the last of those as late as 6e51ca5. So we're back to square one and this PR is no longer applicable, if/when there's something more to do lets start afresh in a new ticket/PR.

Thanks.