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? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
