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/
signature.asc
Description: PGP signature
_______________________________________________ Qbs mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
