Created attachment 160330 [details]
Gecko wants to use signed 16-bit integer audio samples on ARM for performance reasons. Unlike bundled version audio/soundtouch uses 32-bit floats by default. This leads to build failure due to discrepancy of configured sample type.
dnl Use integers over floats for audio on B2G and Android
dnl (regarless of the CPU architecture, because audio
dnl backends for those platforms don't support floats. We also
dnl use integers on ARM with other OS, because it's more efficient.
if test "$OS_TARGET" = "Android" -o "$CPU_ARCH" = "arm"; then
#if (defined(__SOFTFP__) && defined(ANDROID))
// For Android compilation: Force use of Integer samples in case that
// compilation uses soft-floating point emulation - soft-fp is way too slow
#define SOUNDTOUCH_INTEGER_SAMPLES 1
$ make -C www/firefox
checking for soundtouch >= 1.8.0... yes
checking MOZ_SOUNDTOUCH_CFLAGS... -I/usr/local/include/soundtouch
checking MOZ_SOUNDTOUCH_LIBS... -L/usr/local/lib -lSoundTouch
checking for soundtouch sample type... float
configure: error: SoundTouch library is built with incompatible sample type. Either rebuild the library with/without --enable-integer-samples, chase default Mozilla sample type or remove --with-system-soundtouch.
Created attachment 160335 [details]
QA: poudriere testport -j armv6
Created attachment 160363 [details]
Adjusted against base r287137 to include arm/arm (v7 little endian) and arm/armeb (v7 big endian).
Created attachment 160364 [details]
I've removed the softfp for armv6 because it turns out that it's too ambiguous for the arm developer community to sign off on. I was premature, it seems, in pushing it upstream. It's defined for arm and armeb, but I doubt anybody will be running sounttouch / mozilla there. Sorry for any hassles this causes.
armv6 is softfp ABI. However, it has full floating point support, so it should likely use it on armv6 unless measurements prove it too slow.
ports r395349 unbroke configure www/firefox on armv6 while breaking on arm and armeb. armv6 build still fails due to clang crash, though.
Since MACHINE_CPU still exposes softfp on some architectures I plan to land the patch here after approval or maintainer timeout. If softfp in MACHINE_CPU is renamed to something less ambiguous in future it shouldn't be hard to find all makefiles that check softfp and update them.
A commit references this bug:
Date: Thu Sep 17 18:53:19 UTC 2015
New revision: 397202
audio/soundtouch: adjust options
- Make INTEGER_SAMPLES default on platforms with emulated floating point
to be in sync with r395349 
- Fix SSE detection on 9.x by requesting a modern compiler with cpuid.h 
PR: 202642 , 202646 
Approved by: maintainer timeout (3 weeks)
Thanks. Committed. Cannot close because our bugzilla is too pedantic:
Bug 202642 has 1 unresolved dependency. They must either be resolved or removed from the "Depends on" field before you can resolve this bug as FIXED.
Is this still relevant?