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

[Reinhard Tartler]

On Sun, Jul 24, 2011 at 18:56:21 (CEST), Kurt Roeckx wrote:

> On Sun, Jul 24, 2011 at 05:39:20PM +0200, Reinhard Tartler wrote:
>> On Sun, Jul 24, 2011 at 13:07:11 (CEST), Philipp Kern wrote:
>> 
>> > On Sun, Jul 24, 2011 at 12:59:11PM +0200, David Kuehling wrote:
>> >> Well, if it allows people like me to just do 'apt-get source' and
>> >> 'dpkg-buildpackage' without thinking about which kernel they run, it
>> >> does more good than harm, doesn't it :)
>> >> 
>> >> 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.

I think so, but have a look yourself:

http://git.libav.org/?p=libav.git;a=blob;f=libavcodec/mips/mathops.h

For more specific questions, I fear you have to ask the author of the
file directly.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4