On Wed, Aug 12, 2015 at 11:27:37 +0100, Simon McVittie wrote: > On 12/08/15 10:40, Julien Cristau wrote: > > sadly the tpu build on armhf failed, log at > > https://people.debian.org/~jcristau/iceweasel_38.1.1est-1~deb9u1_armhf.log.txt > > It looks as though this is the logic in debian/upstream.mk (to deal with > backports in an automated way), combined with the fact that the > Mozilla-provided replacement build system for the bundled libvpx doesn't > actually compile on armhf due to an assumption made in > media/libvpx/moz.build. > > I compared your build log with a successful build in sid, > <https://buildd.debian.org/status/fetch.php?pkg=iceweasel&arch=armhf&ver=38.1.1esr-1&stamp=1438939440>. > Both have libvpx-dev_1.4.0-4 installed. > > In the successful build, the system libvpx is selected > (-DMOZ_NATIVE_LIBVPX=1). > > In the failing build, the bundled libvpx is selected instead > (-DMOZ_NATIVE_LIBVPX=) resulting in compilation of the bundled > bilinearpredict_neon.c, which for some reason is explicitly compiled > with -mfloat-abi=softfp in media/libvpx/moz.build. That won't work on a > pure armhf system because it tries to include <gnu/stubs-soft.h>, which > only exists on softfloat (armel). > > This seems to be because debian/upstream.mk sets BACKPORT to 1 based on > my choice of version number, and debian/rules responds by setting > LESS_SYSTEM_LIBS to 1, resulting in the use of a bundled nspr, nss, > sqlite and vpx. > > The shortest path to a working t-p-u build is probably to version it > 38.2.0esr-1~stretch (or something) instead of ~deb9u1. Does that make sense? > Thanks for the detective work. 38.2.0esr-1~stretch it is... Cheers, Julien
Attachment:
signature.asc
Description: Digital signature