This reverts commit bfb8df2ad9.
With current toolchains it was not possible to trigger the bug anymore.
Tested with these settings:
BR2_i386=y
BR2_x86_i586=y
BR2_GCC_VERSION_4_8_X=y
BR2_i386=y
BR2_x86_i586=y
BR2_GCC_VERSION_5_X=y
BR2_i386=y
BR2_x86_i586=y
BR2_GCC_VERSION_6_X=y
Other x86 variants also work:
BR2_i386=y
BR2_x86_i486=y
BR2_GCC_VERSION_5_X=y
BR2_i386=y
BR2_x86_i686=y
BR2_GCC_VERSION_5_X=y
BR2_i386=y
BR2_x86_pentium_mmx=y
BR2_GCC_VERSION_5_X=y
BR2_i386=y
BR2_x86_corei7=y
BR2_GCC_VERSION_5_X=y
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We want to use SPDX identifier for license string as much as possible.
SPDX short identifier for LGPLv2.1/LGPLv2.1+ is LGPL-2.1/LGPL-2.1+.
This change is done using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/LGPLv2.1(\+)?/LGPL-2.1\1/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We want to use SPDX identifier for license strings as much as possible.
SPDX short identifier for GPLv2/GPLv2+ is GPL-2.0/GPL-2.0+.
This change is done by using following command.
find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/\<GPLv2\>/GPL-2.0/g'
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There does not appear to be a way to configure the example code
installation, so this mod gets rid of it with a post-install hook.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream has dropped SDL support for ffplay in favor of SDL2.
This results in silently not building ffplay even if it is selected
in Buildroot config.
[Peter: propagate !static dependency from sdl2]
Signed-off-by: Phil Eichinger <phil@zankapfel.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Support for libfaac was removed upstream:
dc0f711459
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg only needs the imgproc module of opencv:
15708f1347
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg 3 fixed support for mips64r2 and mips64r6, for details see
http://patchwork.ozlabs.org/patch/626756/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This option is needed to prevent this message from configure:
WARNING: unknown CPU. Disabling all MIPS optimizations.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas:
- group with the other --cpu conditions so that only one is passed.
- improve the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current logic to pass the --{enable,disable}-mipsfpu option is:
ifeq ($(BR2_MIPS_SOFT_FLOAT),y)
FFMPEG_CONF_OPTS += --disable-mipsfpu
else
FFMPEG_CONF_OPTS += --enable-mipsfpu
endif
In practice, this means that on MIPS soft-float, --disable-mipsfpu is
passed, and that in *all* other cases, --enable-mipsfpu is passed,
including if we are *not* targetting the MIPS architecture.
Even though this doesn't seem to cause any problem, it is a bit weird to
see --enable-mipsfpu when you're building ffmpeg for a non-MIPS
architecture, so we better fix this by enclosing the MIPS-related
options in a MIPS condition.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When BR2_ARM_CPU_HAS_NEON=y, we pass --enable-neon. However, when
BR2_ARM_CPU_HAS_NEON is disabled, we don't pass anything. This generally
works fine, but turned out to integrate NEON code in ARMv7-M
builds (since it's ARMv7, ffmpeg assumed it should enable NEON code).
Even though ffmpeg is now disabled for ARMv7-M, it still makes sense to
be explicit, and disable NEON support when the CPU doesn't have it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In the ffmpeg code, libavutil/arm/asm.S makes some assumption about the
ARM architecture for which the code is built. Only ARMv4, ARMv5, ARMv6
and ARMv7-A is supported. Due to this, object files built out of
ARM-optimized assembly code have the wrong architecture information,
causing a failure at link time.
Adding ARMv7-M support would be possible, but it doesn't exist yet in
ffmpeg, and it's pretty unlikely that ffmpeg will ever be needed on an
ARMv7-M platform, so this commit takes the simple approach of disabling
ffmpeg for ARMv7-M.
Fixes:
http://autobuild.buildroot.net/results/ca4c67b093afd6f14349fcdc87b02e0480172e8c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS architecture detection is not accurate and is always detected as
mips64 even if we are using mips64r2 or mips64r6. Due to that, ffmpeg's
build system will pass the -mips64 flag which will conflict with the
-march option that our toolchain wrapper uses, and it will fail to build
showing errors like this one:
error: '-mips64' conflicts with the other architecture options, which
specify a mips64r2 processor
This problem has been already fixed upstream, but we would need to
backport 17 patches plus some changes in the ffmpeg.mk file. This is too
much, so better to just disable ffmpeg for mips64r2 and mips64r6 for the
upcoming Buildroot release.
This commit can be reverted in the next ffmpeg's version bump.
Fixes:
http://autobuild.buildroot.net/results/7fd/7fd8187c0110cdcac622e667f4a81d2db84f11ef/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg was already marked as not available for the NIOS2 Sourcery
toolchains, but it could still be built with the internal toolchain
backend or a custom external toolchain.
However, an inspection of the latest glibc source code indicates that
FE_INVALID, FE_OVERFLOW and FE_UNDERFLOW and indeed not available in
the nios2 variant of <fenv.h>.
Consequently, this patch makes ffmpeg not available on nios2, which
allows to simplify a bit the dependencies.
It propagates this dependency to:
- minidlna (and at the same time makes sure the minidlna comment is
not displayed on nios2, which wasn't properly taken into account
until now)
- mpd
- opencv
- opencv3
- squeezelite
- tovid
Even if it selects ffmpeg, Kodi does not need an update since Kodi is
only available on a limited number of architectures (which don't
include nios2, obviously). Other packages only make use of ffmpeg when
available.
Fixes:
http://autobuild.buildroot.org/results/921/9212f5a6432c5e695ac0630695405cea05e28610/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Grab the content of BR2_PACKAGE_FFMPEG_EXTRACONF after guessing the CPU,
so the user will still have the possibility to override it.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Disable libcdio and libilbc since they are incompatible with ffmpeg.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
DSP support depends on the core implementation, not on the ISA, so
enabling it for mips64r2 is not correct since you can build a mips64r2
core without DSP support.
Disable mipsdspr1 and mipsdspr2 options by default and let the user
enable them via the BR2_PACKAGE_FFMPEG_EXTRACONF kconfig option, which
will take preference and override the default values.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
0016-ranlib.patch is not needed anymore since the problem that it fixes
is already handled upstream:
2c77ca459e
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
