[ Sorry for entangling the armhf bug with the i386 stuff, subsequent replies should probably remove debian-arm and the bug report from them. ]
On Fri, 2011-02-18 at 13:30:19 +0100, Matthias Klose wrote: > On 18.02.2011 11:13, Guillem Jover wrote: > >[ CCing Matthias, as I'd like your opinion on my proposed solution > > involving some Debian gcc changes. ] > > The armhf patch for gcc looks ok, however I would like to see this > better addressed in Linaro and/or upstream. Ok, I'll run it through upstream to see what they say. I just wanted to check if you'd be fine including it regardless of upstream's stance on it, to at least be able to decide on the armhf triplet issue, the multiarch paths decision would be unrelated to this then. > >> Yes but x86 goes to the other extreme, with separate triplets for > >> compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the > >> triplet is not a good ABI specifier. > > > >Sure, but as mentioned above, I'm now convinced the correct solution is > >to switch back to i386-linux-gnu. > > No, this doesn't work. the triplet currently is set to > i586-linux-gnu. Switching back to to i386 would loose the sync > primitives and a not working gomp. There is too much relying on >= > i586 in many configure's of other packages. Oh, I think this actually strengthens my point! The gcc-4.4:i386 package seems to be compiled on Debian to target i586 as the base instruction set, as can be seen in its debian/rules2:388, which implies changing the triplet would not affect this (barring the small change I'm attaching a patch for, untested), and thus the sync primitive and gomp would be fine (at least from my understanding of the gcc build system). And just to make this perfectly clear, I'm not proposing to downgrade the actual instruction set base line. So while the base instruction set was changed to i586 in gcc 4.4.0-1~exp1 it did not switch the GNU triplet to i586-linux-gnu to match: $ dpkg --print-architecture i386 $ gcc-4.4 -dumpmachine i486-linux-gnu $ gcc-4.5 -dumpmachine i486-linux-gnu $ gcc-4.6 -dumpmachine i486-linux-gnu $ grep ^i386 /usr/share/dpkg/cputable|tr -s '\t '|cut -f2 i486 So I don't see how any debian/rules could be currently relying on the i586-linux-gnu triplet (as long as they set them correctly through the dpkg-architecture variables, coming from gcc, and not from config.guess). Also having to transition all our packaging to the new triplet every time i386 changes the base line does not seem right, and it's something we don't do on any of the other architectures. I'd even say it's just wrong, packages should either use the default compiler base instruction set, set their required one independenly of it, do multiple builds and use hwcaps for libraries or do run time detection. Given the above we'd need to either switch to i586-linux-gnu or i386-linux-gnu, it seems to me both will imply the same amount of changes? And thus going for the latter seems the correct solution, it matches with the other architectures, can be used as the multiarch paths and can reduce some divergence with Ubuntu, all of them a clear win! :) > Not only for the good, as the switch in Ubuntu to i686 did show, > because many configure files assume sse with i686-linux-gnu. I'd say any such assumption in those packages is buggy, per above. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org