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

[peter green]

On 13/08/15 00:05, Simon McVittie wrote:
> 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
>    
Yeah, it sucks that there is no system in place to publish logs for 
security packages along with the packages themselves.
> The iceweasel packaging automatically adapts itself to be suitable for
> backports when it sees ~bpo or ~deb in the version number:
yuck
>   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.
Using a non-default ABI seems like a good way to break stuff and afaict 
few people care about OABI anymore. I doubt this was the reason.

> On ARM EABI softfloat (armel),
> -mfloat-abi=softfp is equivalent to the default, and is harmless.
>    
No it's not equivilent to the default. The default on armel is 
mfloat-abi=soft which disables the FPU completely. mfloat-abi=softfp 
uses the soft-float ABI but allows the compiler to use the FPU

So if you are going to build an alternative code path/version of a 
binary for armel that uses the fpu (obviously there must be a non-fpu 
based codepath/binary as well as presense of a VFP FPU is not 
gauranteed) then you need to use -mfloat-abi=softfp.
> 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:
code that tries to use the soft float abi on debian armhf is going to be pretty broken, so it's probablly a good thing that it fails to build.