Bug#738760: libav: Add proper raspberry pi CPU detection

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2014-09-26 13:12:42, Janne Grunau wrote:
> On 2014-09-05 00:17:15 +0200, Florian Will wrote:
> > Hi,
> > 
> > Please note that I'm not the bug submitter.
> > 
> > > Can you provide a patch, please?
> > 
> > As of now, I can't. :/ I don't have the hardware to reproduce this or to
> > verify the correctness of a patch.
> > 
> > So I can only give a few hints about the background of this bug report.
> > Anyone not planning to come up with a patch can probably skip it. :-)
> > 
> > > I don't know much about raspbian, and don't understand what you
> > > actually want to be changed here.
> > 
> > I've used raspbian some time ago. The issue with some packages is that
> > they enable ARM NEON instructions (and other illegal instructions?)
> > during compilation, either generally for the armhf architecture, or
> > based on what the build machine supports. The Raspberry Pi is armhf, but
> > does not support NEON. Raspbian buildds *do* probably support NEON though.
> > 
> > The Raspbian toolchain is configured to disable NEON. However, libav
> > apparently still ends up with NEON instructions in the binary.
> 
> That is not a problem. If NEON is disabled in the toolchain there will 
> be still NEON specific asm included which will be only used if a CPU 
> with NEON is detected at runtime. I'm quite certain that this works as 
> intended.
> 
> > Surprisingly, NEON is supposed to get enabled for libav only if the
> > "debian/confflag" script detects that the toolchain supports NEON.
> > 
> > Still, for the libav package in Raspbian, this line was changed:
> >     #RPI -- don't build neon flavour
> >     #FLAVORS += neon
> 
> That's now how I read the debian/confflags in 
> http://security.debian.org/debian-security/pool/updates/main/liba/libav/libav_0.8.16-1.debian.tar.gz
> 
> It checks if the toolchain supports NEON and other things by default. If 
> it does *not* support NEON, the debian package will build a additional 
> NEON flavor of the package. Building that flavor is quite pointless if a 
> single CPU without NEON is targeted. So disabling that in raspbian makes 
> sense.
> 
> Building a NEON flavor makes sense for general distribution like Debian 
> that will run on different CPUs with different supported instruction set 
> extensions.
> 
> That is the only relevant change I see in debian/ for the libav src 
> package.
> 
> So unless the original patch reported specifies what he wants exactly 
> I'd say everything is fine and working as expected.
> 
> The only minor issue is that if the toolchain uses NEON by default and 
> one uses '-mfpu=' to disable it, the check will be wrong. I don;t think 
> any of the debian toolchains are configured this way though.

Hi Peter,

there was a request to change the handling of the Raspberry Pi in the
libav package. Could you please explain the changes applied to the
Raspbian version? To me it looks like there's nothing wrong with the
package, but that you have applied some flags to optimize for the
Raspberry Pi? Is my understanding of the situation correct?

For the record, this is the current diff:

diff -Nru libav-11/debian/changelog libav-11/debian/changelog
--- libav-11/debian/changelog   2014-10-19 22:20:25.000000000 +0200
+++ libav-11/debian/changelog   2014-11-26 23:05:30.000000000 +0100
@@ -1,3 +1,11 @@
+libav (6:11-2+rpi1) jessie-staging; urgency=low
+
+  * Disable build of neon flavour
+  * Disable armv6t2 and neon for regular flavours
+  * Disable runtime cpu detection
+
+ -- Peter Michael Green <plugwash at raspbian.org>  Wed, 26 Nov 2014 22:05:05 +0000
+
 libav (6:11-2) unstable; urgency=medium
 
   * add patches post v11 release, all of which will be included in the 
diff -Nru libav-11/debian/confflags libav-11/debian/confflags
--- libav-11/debian/confflags   2014-10-19 22:18:26.000000000 +0200
+++ libav-11/debian/confflags   2014-11-26 23:05:30.000000000 +0100
@@ -47,7 +47,8 @@
     endif
     # only build a NEON flavour if the toolchain doesn't enable NEON by default
     ifneq ($(has_neon),1)
-    FLAVORS += neon
+    #RPI -- don't build neon flavour
+    #FLAVORS += neon
     endif
     # calling-conventions for VFP and NEON flavours: if the toolchain uses
     # -mfloat-abi=soft, we want to use softfp, otherwise we want to use the
@@ -97,12 +98,13 @@
 # Common configuration flags
 confflags += --arch='$(DEB_HOST_ARCH_CPU)'
 confflags += --enable-pthreads
-confflags += --enable-runtime-cpudetect
+#confflags += --enable-runtime-cpudetect
 confflags += --extra-version='$(DEB_VERSION)'
 confflags += --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
 confflags += --prefix=/usr
 confflags += $(shell test -x /usr/bin/yasm || echo --disable-yasm )
 confflags += --disable-avserver
+confflags += --disable-armv6t2 --disable-neon
 
 ifeq      ($(DEB_HOST_ARCH),armel)
 # this is required on Ubuntu lucid as it defaults to thumb2 and Libav has

Cheers
-- 
Sebastian Ramacher
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150103/1bba253c/attachment.sig>