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

[jscottkasten]

 From: David Kuehling dvdkh...@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-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: tremor (libivorbis) on mips

[jscottkasten]

--- On Fri, 4/23/10, Reinhard Tartler siret...@tauware.de wrote:

 From: Reinhard Tartler siret...@tauware.de

 (CEST), Thorsten Hirsch wrote:

  decoding ogg on my mips based nas device is slower
 than real-time, so
  it's not really usable here.
  I've already done some research on this and I think
 the reason is that
  the mips cpu has no fpu, so floating point
 calculations are really
  slow. Unfortunately libogg is based on floating point
 calculations.
  But there's also an integer based version of libogg:
 tremor (or is it
  called libivorbis?). It's also available in ffmpeg
 (there's a
  configure parameter --enable-tremor or something
 like that)
 
  And here's my question to you: is it possible to use
 tremor-enabled
  packages on mips instead of the normal ones? Can you
 provide something
  like a ffmpeg (libavcodec) package on mips that
 depends on libivorbis
  instead of libvorbis?

 If the debian-mips porters confirm that there are FPU
 enabled mips
 machines, or they are at least pretty uncommon, then I
 think we should
 add this switch for mips only. CC'ing debian-mips for their
 feedback on
 this.

Here's the deal.  The mips port covers desktop mips systems such as SGI's and 
embedded mips devices such as PDA's.  Desktop mips chips have decent floating 
point units, while embedded mips chips traditionally have not.  Traditionally, 
the desktop mips have usually run big endian, and the embedded have usually 
been little endian.  (I did say usually.)  The mips port has been divided 
into separate mips and mipsel builds.  Thus you may be able to accomplish such 
a change without offending too many people by targeting mipsel for either the 
fast integer library, or possibly using -msoft-float as a general build-option 
for the media libaries.  (The -msoft-float flag causes gcc to emit emulation 
code in the binary itself, thus avoiding the costly overhead of the kernel 
emulation for the missing FPU.)

The newer embedded mips chips sometimes do have traditional FPU, or more likely 
some flavor of SIMD.  I'm not aware for general, widespread support for the 
mips SIMD that is out there yet, but it may happen thanks to the wide spread 
demand for embedded multi-media devices.

Cheers,

-S-


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers