Libav 0.7 FTBFS on mipsel: Error: opcode not supported on this processor: mips2 (mips2) `ldl $2, 7($13)'

[David Kuehling]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20110724/d9198548/attachment.pgp>