+++ Robert Schwebel [2010-09-03 09:41 +0200]: > Hi, > > > In OSELAS.Toolchain, we have a set of flags integrated into each > toolchain, so for example for arm-v4t-linux-gnueabi, it generates v4t > code with software floating point without any further flags. I agree on > that it would be a goal to have only one multilib toolchain which can do > everything, but we definitely need wrappers, because compiling a hello > world should still be > > $(GCC) hello.c -o hello
Yep, this is the thing you need to work well once you move to using distribution toolchains instead of 'rebuild for my target and my defaults'. It has annoyed me for years that this was not an easy thing to do. I am not a toolchain engineer either (so feel free to correct anything incorrect about my understanding below), but I am sat in a room with some now, which may prove helpful to making some progress on this issue in the Debian context. The way gcc builds multilib currently does not support making one toolchain that supports lots of ouput options well, because you get a cross-product number of multilibs built for the options you are trying to support. That works well for 2 or three, but rapidly becomes madness (and toolchains build times get very long). Codesourcery are working on improving this. Discussion here: http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html As you say, wrappers are the only practical way of setting defaults right now, although I'd really like to see the compiler grow some kind of config file you could set some defaults in, like normal software (or someone explain to me why that can't be done or isn't sensible). I really don't see why one has to set target arch/CPU/preferred optimisations on _every_ command line, rather than in a config file. specs files help somewhat here but are sufficiently impenetrable to not be much use to developers that just want to set some defaults. They could work OK for distro-supplied 'gcc-settings' packages. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
