On Wed, 2019-02-27 at 23:45 +0000, Steve McIntyre wrote: > On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote: > > On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre <st...@einval.com> wrote: > > > So, I've got to ask - what hardware are you likely targeting here > > > where it matters to build stuff for armel yet also use NEON if it's > > > available? Most people with hardware that *can* do NEON should be > > > using armhf, surely? > > > > Yeah, I know what you are saying. > > > > The problem in practice with mainstream compilers is (1) ARM and the > > ACLE defines are a mess, (2) -march=native does not work like on i686 > > or x86_64, and (3) RTFM does not work. > > > > For a regular user who wants to use Debian on ARM we need to figure > > out how to build to the least capable machine (like ARMv5 or ARMv6) > > while making more capable features (like NEON) available. > > So this is a place where the world is just *different* compared to x86 > - the different versions of the ARM architectures have signficantly > different capabilities. If you're looking to build something that > performs well on a modern v7 CPU, compilling for v5 is a > mistake. You'll be using the wrong locking primitives, barriers, > etc. Equally, the features you're going to be looking for (like SMP, > NEON) just don't make sense / don't exist on v5 CPUs.
To spell it out: the gist of this is that it isn't possible to provide a single arm binary which works well for both armel and armhf (which I think is what Jeff is trying/wants to do?). The advice here is to instead ship[0] two binaries -- one targetting v5 (no neon etc, aka armel in Debian) and another targetting v7 (w/ possible(? I forget what is optional) neon and other stuff aka armhf in Debian and other distros). Ian. [0] and/or have the build system detect between.
