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

[David Kuehling]

> On Sun, Jul 24, 2011 at 11:33:42 (CEST), Philipp Kern wrote:
>>> On Sun, Jul 24, 2011 at 12:59:46AM +0200, Bastian Blank wrote:
>>> On Wed, Jul 20, 2011 at 08:52:45PM +0200, Philipp Kern wrote:
>>> > I think that's a misconfiguration of the buildds.  They're
>>> supposed to > put linux32 into the schroot configuration if the
>>> kernel arch differs > from the userspace arch, to get the right
>>> entry into uname.  Negative. The build have to work with even a
>>> complete different kernel architecture.
>> 
>> Since when do we require this?  I don't think we do that.  It might
>> be a goal, which you are free to propose.  (Mainly useful to build
>> the right packages on i386 userland with an amd64 kernel.)  The
>> status quo is that such build failures are not RC, AFAIK.

> In the mean time, I've uploaded this patch:

> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=27301ced78552bd4a95a9502cb67acd58b3fd297

> As far I understand this discussion, it is no longer necessary. Please
> tell me if I should revert it, or if it is a good idea nevertheless.

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.

just my 2 cents.

cheers,

David
-- 
GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20110724/6b730982/attachment.pgp>