+++ John Rigby [2010-10-06 08:31 -0600]: > I'm really sorry to have started this, but for completeness here is > the rest of the story. The hypothetical scenario is a developer that > maintains u-boot for multiple platforms. Using a codesourcery or eldk > (from denx.de) toolchain one can use the appropriate -march= to get > the right code from the compiler. Also the libgcc.a is ARM so all is > well. Using a linaro toolchain using the same -march= you get the > right code from the compiler but the result will get linked with a > Thumb-2 libgcc.a and the resulting binary will not run on an older > ARM. If however libgcc.a was ARM then it would just work. Again, I'm > not saying this is a bug or even something for Linaro to care about. > It just means that the Linaro toolchain is not something that this > hypothetical u-boot maintainer would want to use as his/her one and > only toolchain.
You bring up an issue that has bugged me for a while. The way gcc is currently designed, whilst you can choose compile time options (like -march=arm), that doesn't do what someone who is targeting, say, a v5 machine wants, unless the toolchain was built with the relevant multilib options so that it actually has several libgccs (and potentially libgomps and libmudflaps and whatever else it spits out these days). So in practice you can only really set a 'flavour' (as I shall call the choice of instruction set(s)) at compiler build-time, not package build time. Your average developer would much prefer it if they could easily choose the flavour at build-time of their package/software, and not have to rebuild the toolchain for that flavour first. And we, as distibutors of binary cross-toolchains, would also like to be able to support people targetting multiple flavours with one toolchain, without having to do that by picking lowest-common-denominator, or build lots of different toolchains. gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than that. (i.e if you ask for v5, v6, v7, vfp, and neon options you get 25 versions of libgcc1, most of which are silly combinations) Joseph Myers of Codesourcery has been looking at making this into a more flexible mechanism where you just choose the combinations you actually cared about, not every possible one. I hope that the output of that work would mean we (or someone else like Debian) could choose to support a couple of other useful options, and maybe even a nice runtime way of selecting them. This has not been a huge issue to date because few people were using pre-built packaged cross-toolchains - they were building the toolchain for their target. Of course that's still quite easy to do, and indeed ARM (well, linaro/ARM in the form of ppearse) are doing it internally for v5 and v6 targets for ALIP builds. But they won't/can't make those packages available because of legal paranoia about shipping gcc so someone else should do this outside and make a handy repo. Until then the easiest approach is just to use the emdebian cross-toolchains which are built to Debian armel's v4t-nothumb-novfp maximum-compatibilty flavour: http://emdebian.org/crosstools.html ('binary toolcahins' link). This issue is a useful subject for UDS discussion, I believe. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
