Re: Bug#795331: iceweasel: backport/security builds (bundled libvpx) FTBFS on armhf
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.
Reply to: