Bug#795331: iceweasel: backport/security builds (bundled libvpx) FTBFS on armhf

[Simon McVittie]

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