Bug#760433: libav: FTBFS on x32: Invalid inline assembly

Reinhard Tartler siretart at gmail.com
Sat Sep 13 11:56:40 UTC 2014


On Wed, Sep 3, 2014 at 11:45 PM, Daniel Schepler <dschepler at gmail.com> wrote:
> Source: libav
> Version: 6:11~beta1-2
> Severity: important
> Justification: blocker for kde builds
> X-Debbugs-CC: Thorsten Glaser <tg at mirbsd.de>
>
> When I try building libav in an x32 schroot (without the build dependencies on
> frei0r, opencv, x264 which have also all failed to build on x32), I get this:
>
> ...
> /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c: Assembler messages:
> /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:798: Error: operand type mismatch for `push'
> /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:860: Error: operand type mismatch for `push'
> /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:861: Error: operand type mismatch for `push'
> ...
> /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:1380: Error: operand type mismatch for `pop'
> /tmp/libav/libav-11~beta1/Makefile:44: recipe for target 'libswscale/x86/swscale.o' failed
> make[1]: *** [libswscale/x86/swscale.o] Error 1
> make[1]: Leaving directory '/tmp/libav/libav-11~beta1/debian-static'
> debian/rules:81: recipe for target 'build-stamp-static' failed
> make: *** [build-stamp-static] Error 2
> rm configure-stamp-static
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> I'm attaching the debdiff I'm using for an upload to debian-ports/unreleased.
> You can ignore the debian/control part, and as the debian/rules changes could
> be considered a horrible hack, I'm not tagging this as patch.

I don't think that this is the right solution, the fix should really
go to configure directly. Looking at configure, it already seems to
support --arch=x86_32. Can you confirm that the package calls
configure with that already? If not, then I guess that's the only
thing that we should fix in the packaging.

If the configure gets things wrong, then that's what should get fixed
and upstreamed. Upstream is usually very responsive to porting
patches, and obviously has even thought about x32, so let's join that
effort instead of disabling it.

Regarding porting, please have a look at
http://anonscm.debian.org/cgit/pkg-multimedia/libav.git/tree/debian/README.source:


Circular Build-Depends and bootstrapping libav on new architectures
===================================================================

libav is involved in several circular build-dependencies that give porters a
hard time (c.f. #671302) at bootstrapping, e.g.:

 libav -> frei0r -> opencv -> libav
 libav -> opencv -> libav
 libav -> x264 -> libav
 libav -> x264 -> gpac -> libav

However, please note that all these libraries are strictly optional to libav
and are only enabled at build time if available. For bootstrapping purposes
it is thus perfectly sufficient to remove all *-dev packages from the
Build-Depends field in debian/control and generate packages with a reduced
feature set that are still usable to build other packages.

Using the nomenclature of the EmdebianSprint2011 [0,1] one would write e.g.:

 Build-Depends-Bootstrap1:
  debhelper (>= 9)

[0] http://wiki.debian.org/DebianBootstrap/EmdebianSprint2011
[1] http://lists.debian.org/debian-devel-announce/2011/03/msg00000.html


 -- Fabian Greffrath <fabian+debian at greffrath.com>  Tue, 19 Jun 2012
16:06:05 +0200



-- 
regards,
    Reinhard



More information about the pkg-multimedia-maintainers mailing list