Libav 0.7 FTBFS on mipsel: Error: opcode not supported on this processor: mips2 (mips2) `ldl $2, 7($13)'
kurt at roeckx.be
Sun Jul 24 16:56:21 UTC 2011
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.
More information about the pkg-multimedia-maintainers