On 7 December 2010 18:35, Paul Brook <p...@codesourcery.com> wrote: >> In essence, I would like to express my objection in having the same triplet >> for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they >> just haven't done the extensive compiling I have and didn't consider the >> problems (I doubt anyone else has built ~8000 packages for a hardfloat >> port). > > As the relevant upstream maintainer I'll confirm this objection. In the past > gcc used to try and guess which config to use based on variants of the > triplet. In practice this caused more problems than it solved, especially when > you have a single toolchain that can target multiple variants. > > If you want different triplets then I suggest you use the vendor field. e.g > arm-debian_armel-linux-gnueabi and arm-debian_armhf-linux-gnueabi.
Which is exactly what I am doing. You are right I should be more specific. Right now, armhf uses arm-hardfloat-linux-gnueabi -which as was suggested here uses the vendor field. It works fine, in truth, only a handful of packages break with the vendor field and the fix is trivial. What was suggested to me was that the vendor field should *NOT* be used and a single arm-linux-gnueabi should be used for both softfp and hard ABIs. I'm sorry but especially in the case of compilers and in particular cross-compilers, this just does not work. Unless there is another way of OS (and ABI) detection, like the DEB_HOST_ABI fields, there is no way to know which ABI to compile from. So, my objection is in not keeping the arm-hardfloat-linux-gnueabi triplet. I did not suggest a different triplet altogether, just the ability to use the vendor field and thus in essence make a different triplet -but not too different. Konstantinos _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
