[Qbs] How to pass -march=armv7-a to the g++ linking command line (without -Wl, )

[Wookey]

On 2018-01-16 12:08 +1300, Christian Gagneraud wrote:
> 
> I found this piece of information very interesting indeed, what's your
> stance about -march then? In my case, I have one toolchain per platform
> (roughly), they all have the same generic triplet (arm-linux-gnueabi), but
> target different ARM arch (armv5te, armv6, cortex A?, ...) and actually have
> sometimes different float ABI.

I think you are doing it wrong, in more than one way :-)

I like to distinguish between ISA (instruction set) and ABI
(Application Binary Interface). An 'architecture' in Debian is
actually an ABI (not a machine, nor a CPU). That never changes for the
lifetime of the architecture. The ISA that arch is built with can
change over time as newer hardware becomes a sensible default i386->
i486 -> i686 in the i386-linux-gnu ABI, and armv4t -> armv5 -> armv7
in the arm-linux-gnueabi ABI, for example.

A platform is a combination of ISA and ABI. It may be able to run more
than one ABI, but when you chose an OS it all has to have a matching
ABI so that libraries work together. It has a 'natural' ISA it can
run, but it can generally run all older ones too (some exceptions,
especially with mips). Binary distros pick a base (old, generic) ISA
to use that will work everywhere. If you are building everything for
yourself then you can optimise for the specific platform.

So you should have a toolchain for each ABI, not for each
platform. Which ISA you default it to, or set your builds to, depends
on what hardware you expect the code to be run on/optimised
for. Changing the ISA you build for on a particular build (e.g. to
optimise for particular hardware) does not change the ABI so stuff
will still link and work together with other libraries.

If you get this distinction straight in your head it generally helps
with thinking about this stuff (which is quite messy on some
architectures, like 32-bit arm and mips).

Obvsiouly there are toolchains which can produce output for more than
one ABI with the right incantations (-m32 on x86_64-linux-gnu compiler
will generate i386-linux-gnu ABI, and -mfloat-abi=hard-float on
arm-linux-gnueabi compiler will get you you arm-linux-gnueabihf ABI),
but the problem with all these magic options is that they are specific
to particular toolchain+ABI tuples and are not consistent between
architectures. This makes them a pain for upstreams and build systems
and best avoided by just letting the build set HOST=<triplet> and
using that. Obviously there are arch-specific ISA and optimisation
settings. Upstreams should try to avoid setting these (they don't know
what they will be built for) but you can always set them at build time
if you know what you want.

Does that all make sense. Are we off-topic for this mailing list yet?

> PS: Glad to see you on this ML, I remember you from the Emdebian project
> when I gave it a try, that was 10 years ago! ;)

Yep - that was me :-)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20180116/01cb9078/attachment.sig>