Created attachment 160330 [details] v0 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 https://dxr.mozilla.org/mozilla-central/rev/ba43a48d3c52/configure.in#5022 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 MOZ_SAMPLE_TYPE_S16=1 AC_DEFINE(MOZ_SAMPLE_TYPE_S16) AC_SUBST(MOZ_SAMPLE_TYPE_S16) else MOZ_SAMPLE_TYPE_FLOAT32=1 AC_DEFINE(MOZ_SAMPLE_TYPE_FLOAT32) AC_SUBST(MOZ_SAMPLE_TYPE_FLOAT32) fi // http://sourceforge.net/p/soundtouch/code/226/tree/trunk/include/STTypes.h #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 #undef SOUNDTOUCH_FLOAT_SAMPLES #define SOUNDTOUCH_INTEGER_SAMPLES 1 #endif $ 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. http://beefy8.nyi.freebsd.org/data/head-armv6-default/p395013_s287011/logs/firefox-40.0_6,1.log
Created attachment 160335 [details] QA: poudriere testport -j armv6
Created attachment 160363 [details] v1 Adjusted against base 287137 to include arm/arm (v7 little endian) and arm/armeb (v7 big endian).
Created attachment 160364 [details] v2 Simplified.
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. http://beefy8.nyi.freebsd.org/data/head-armv6-default/p395445_s287222/logs/firefox-40.0_6,1.log 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: Author: jbeich Date: Thu Sep 17 18:53:19 UTC 2015 New revision: 397202 URL: https://svnweb.freebsd.org/changeset/ports/397202 Log: audio/soundtouch: adjust options - Make INTEGER_SAMPLES default on platforms with emulated floating point to be in sync with r395349 [1] - Fix SSE detection on 9.x by requesting a modern compiler with cpuid.h [2] PR: 202642 [1], 202646 [2] Approved by: maintainer timeout (3 weeks) Changes: head/audio/soundtouch/Makefile
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?