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

[jscottkasten at yahoo.com]

> From: David Kuehling <dvdkhlng at gmx.de>
> Subject: Re: Libav 0.7 FTBFS on mipsel: Error: opcode not supported on this processor: mips2 (mips2) `ldl $2, 7($13)'

> >>> 
> >>> Forcing ./configure --arch=mips/mipsel might
> help.
> >> 
> >> That makes sense to me. I'll add
> --arch=$(DEB_BUILD_CPU) to the
> >> configure line for the next upload.
> >> 
> 
> > Why aren't the builds done under 'linux32'? 
> Doing that would cause
> > uname to return the proper values for an o32 build.
> 
> The complete userspace *is* o32, just the kernel is
> not.  I think that
> is a pretty valid way to run a system, compiling the kernel
> for mips64
> gives better performance on those machines that can run
> mips64 code.
> 
> A mips64 kernel can run 32 and 64-bit architecture
> binaries, and has to
> pick one description when asked via 'uname -m'.  The
> 'setarch' tool can
> be used to configure which architecture that is.
> 
> I.e. athough my machine usually returns 'mips64' on 'uname
> -m', after
> running, 'setarch mips' it returns just 'mips'.  Maybe
> that'd be a a
> cleaner way to fix the problem for all package builds?
> 
> cheers,
> 
> David

Someday, in an ideal world with full multilib support, mips and mips64 both become valid targets on the same host.  There are a lot of packages whose configure script is dumbed down to assume mips when uname returns mips64.  Still, I've always used the configure argument and/or environment to make it explicit that I'm building 32 bit.

-S-