Libav 0.7 FTBFS on mipsel: Error: opcode not supported on this processor: mips2 (mips2) `ldl $2, 7($13)'
siretart at tauware.de
Sun Jul 24 17:26:24 UTC 2011
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:
For more specific questions, I fear you have to ask the author of the
Reinhard Tartler, KeyID 945348A4
More information about the pkg-multimedia-maintainers