> On Sun, Jul 24, 2011 at 05:39:20PM +0200, Reinhard Tartler wrote: [..] >> >> Maybe the really correct, and right way to fix that, though, is to >> patch >> the configure script to check for the ABI used by $CC >> instead of 'uname >> -m'. That kind of fix could then also go >> upstream. >> > >> > Normally you pass the right build triplet coming from dpkg to >> configure through > debian/rules, though. So it shouldn't rely on >> uname. >> >> Well, I've discussed this upstream before implementing the change >> I've pointed to earlier in this thread. The upstream configure script >> does check the ABI of CC on every arch but mips. On mips, I was told >> this wasn't possible because mips was special there were so many ABIs >> there. > Why does it need to check an ABI? Does it contain some assembler > versions of some functions and need to know the ABI for that? Because > that's about the only reason I can think of why something would want > to know the ABI. It uses the architecture information mips64 vs. mips to #ifdefs inline assembler code that makes use of 64-bit operations. On MIPS for some strange reason, people seem to only use 64-bit operations if the program is compiled for n32, n64 or o64 ABI, because o32 ABI lacks proper 64-bit support. Especially the stack is not 64-bit aligned on o32. Eg. GCC won't generate any 64-bit operations for 'long long' in o32 mode, even if you tell it that the CPU supports these operations. Also n32, n64 and o64 ABIs only run on 64-bit capable MIPSes anyways, so that makes any run-time CPU detection unneccessary. Other than that you're right. It doesn't really want to know the ABI, it's only interested in whether the target has 64-bit support. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Attachment:
pgpZx1jAZIDFB.pgp
Description: PGP signature