ffmpeg: do not build on m68k coldfire
authorThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mon, 29 May 2017 21:31:51 +0000 (23:31 +0200)
committerThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mon, 29 May 2017 21:31:51 +0000 (23:31 +0200)
m68k coldfire causes ffmpeg to think atomic intrinsics are available,
so ffmpeg doesn't use its fallback on pthreads based atomic
operations. However, m68k coldfire doesn't provide properly working
sync 4 atomics, causing a build failure.

Since fixing ffmpeg on m68k coldfire is not really important (who
wants to use ffmpeg on such platform?), we simply disallow the
selection of ffmpeg on this platform.

Alternate approaches have been proposed in the past:

 - Bernd Kuhls proposed in http://patchwork.ozlabs.org/patch/766909/
   to add a dependency on BR2_TOOLCHAIN_HAS_SYNC_4, but this is wrong
   because other architectures that lack sync 4 atomics, such as
   Sparc, can build ffmpeg perfectly fine thanks to the pthreads based
   fallback code.

 - Waldemar Brodkorb proposed in
   https://patchwork.ozlabs.org/patch/756664/ to add an explicit
   option in ffmpeg configure to force the use of pthreads based
   atomics. However, we believe that running ffmpeg on m68k coldfire
   is such an unlikely use case that it isn't worth carrying a patch
   for this.

Fixes:

  http://autobuild.buildroot.net/results/b3e/b3eaaf6d73cd49f5919143aeaa5cbb4d15a7ccc3/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
package/ffmpeg/Config.in

index 383374ddbef5da2cd45209ead30319fb03ff9484..279f94f0d1ccc4cc411695e27b14ba02b983cee6 100644 (file)
@@ -3,7 +3,13 @@ config BR2_PACKAGE_FFMPEG_ARCH_SUPPORTS
        # fenv.h lacks FE_INVALID, FE_OVERFLOW & FE_UNDERFLOW on nios2
        # No support for ARMv7-M in the ARM assembly logic
        # Microblaze build affected by gcc PR71124 (infinite loop)
-       default y if !BR2_nios2 && !BR2_ARM_CPU_ARMV7M && !BR2_microblaze
+       # m68k coldfire causes a build failure, because the check for
+       # atomics (atomic_store) succeeds, which causes ffmpeg to
+       # think atomic intrinsics are available, while they are
+       # not. See https://patchwork.ozlabs.org/patch/756664/ and
+       # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 for more
+       # details.
+       default y if !BR2_nios2 && !BR2_ARM_CPU_ARMV7M && !BR2_microblaze && !BR2_m68k_cf
 
 menuconfig BR2_PACKAGE_FFMPEG
        bool "ffmpeg"