Package: iceweasel Version: 38.1.1esr-1 Severity: important [X-Debbugs-Cc: debian-arm to get an expert opinion on how the ABIs fit together]
As described on <https://bugs.debian.org/795079>, a rebuild of iceweasel/38.1.1esr-1 with ~deb9u1 appended to the version number, in a stretch environment, failed to build from source on armhf. Build log: <https://people.debian.org/~jcristau/iceweasel_38.1.1est-1~deb9u1_armhf.log.txt> I worked around this by using ~stretch instead of ~deb9u1 for the subsequent 38.2.0 upload. I suspect this might also be affecting 38.2.0esr-1~deb8u1 in the security archive. security.debian.org offers 38.2.0esr-1~deb8u1 for armel but not armhf, which supports this theory. However, security buildds don't publish their logs to avoid leaking details of embargoed packages, so I can't say for sure whether the missing build is due to a slower-than-armel build, this bug, or a different FTFBS. The iceweasel packaging automatically adapts itself to be suitable for backports when it sees ~bpo or ~deb in the version number: in particular, it uses a few bundled libraries, including libvpx, instead of the system equivalents. If I had re-generated control.in from control, it would also have dropped the corresponding build-dependencies, but for a t-p-u upload I didn't particularly want to do that. Instead of its upstream build system as used in src:libvpx, the bundled libvpx in iceweasel is built using media/libvpx/moz.build, which has this code: if CONFIG['VPX_ARM_ASM']: ... for f in SOURCES: if f.endswith('.c') and 'neon' in f: SOURCES[f].flags += ['-march=armv7-a', '-mthumb', '-mfloat-abi=softfp', '-mfpu=neon'] I assume this is present so that the NEON-optimized files will be built with the softfp ABI on ARM OABI (the deprecated "arm" architecture in Debian), which used a different ABI by default. On ARM EABI softfloat (armel), -mfloat-abi=softfp is equivalent to the default, and is harmless. Unfortunately, on ARM EABI hardfloat (armhf), the use of -mfloat-abi=softfp causes glibc to take the softfloat code path in <gnu/stubs.h>: #if !defined __ARM_PCS_VFP # include <gnu/stubs-soft.h> #endif #if defined __ARM_PCS_VFP # include <gnu/stubs-hard.h> #endif In Debian, <gnu/stubs-soft.h> only exists on armel, while <gnu/stubs-hard.h> only exists on armhf, so this fails: In file included from /usr/include/features.h:398:0, from ../../dist/system_wrappers/features.h:3, from /usr/include/stdint.h:25, from /usr/lib/gcc/arm-linux-gnueabihf/4.9/include/stdint.h:9, from ../../dist/system_wrappers/stdint.h:3, from /usr/lib/gcc/arm-linux-gnueabihf/4.9/include/arm_neon.h:38, from /«PKGBUILDDIR»/media/libvpx/vp8/common/arm/neon/bilinearpredict_neon.c:11: /usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:29: fatal error: gnu/stubs-soft.h: No such file or directory # include <gnu/stubs-soft.h> ^ compilation terminated. make[5]: *** [bilinearpredict_neon.o] Error 1 I suspect that the solution to this might be to stop using -mfloat-abi=softfp: if it was there to support ARM OABI, then it no longer matters even for Debian 6 (squeeze) LTS, since arm was replaced by armel in Debian 5. However, I am not an expert on ARM, NEON or Mozilla, so someone who knows better should definitely check my reasoning. Regards, S
