> From: David Kuehling <[email protected]> > 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- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
