It fixes runtime issues with ffmpeg 3.1.x
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Switch to homepage download URL to get the smaller xz-compressed variant.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Drop all of the upstreamed patches (not precisely in the same form) and
rebase the only required patch for proper static builds with staging
libs required by other packages.
Build-tested for arm-glibc, arm-uclibc, arm-musl and arm-uclibc-static.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This new patch does change behavior, but it was accepted by upstream and
could be removed on next version bump.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's wayland, not waylandd, hence gtk3+ with the wayland backend went
completely poof.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes a compile error not yet caught by autobuilders:
In file included from /home/bernd/buildroot/br2/output/build/kodi-pvr-vbox-15e864d160da5a051e18aef06f3a53e49808be02/src/client.cpp:24:0:
/home/bernd/buildroot/br2/output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/kodi/xbmc_pvr_dll.h:423:63: error: 'SEEK_SET' was not declared in this scope
long long SeekLiveStream(long long iPosition, int iWhence = SEEK_SET);
^~~~~~~~
/home/bernd/buildroot/br2/output/host/usr/i586-buildroot-linux-uclibc/sysroot/usr/include/kodi/xbmc_pvr_dll.h:510:67: error: 'SEEK_SET' was not declared in this scope
long long SeekRecordedStream(long long iPosition, int iWhence = SEEK_SET);
^~~~~~~~
CMakeFiles/pvr.vbox.dir/build.make:62: recipe for target 'CMakeFiles/pvr.vbox.dir/src/client.cpp.o' failed
using this defconfig
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_BINUTILS_VERSION_2_26_X=y
BR2_GCC_VERSION_6_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_INIT_NONE=y
BR2_PACKAGE_KODI=y
BR2_PACKAGE_KODI_PVR_VBOX=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_I965=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_XORG7=y
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The fix from commit 26248571b6 ("micropython: fix build failures") was
applied upstream. This replaces the local buildroot fix with the patch
that was accepted upstream.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng011.
This engenering build contains the following updates:
1. rebase binutils on top of the latest upstream master
2. update GCC to version 6.2
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- Upstream patches removed.
- Do not autoreconf since this was neecessary for one of those patches
that are now upstream. Also remove host-gettext dependency for the
same reason.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ERROR: reloc type R_ARM_THM_MOVW_ABS_NC unsupported in this context
ERROR: reloc type R_ARM_THM_MOVT_ABS unsupported in this context
2 bad relocscollect2: error: ld returned 1 exit status
Binutils build fine with -O1, -O2 or -O3.
Reported upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20552
Fixes:
http://autobuild.buildroot.net/results/e72/e727e6e9cf361acc786acec192a88f5f5444a2f6
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libjpeg and jpeg-turo are providers of the jpeg virtual package, so they
must declare themselves as such.
We do not have any problem, because the dependency is computed from the
Kconfig-defined option BR2_PACKAGE_PROVIDES_JPEG, and we do not check
the Makefile-defined <FOO>_PROVIDES variable.
For the sake of correctness, make both libjpeg and jpeg-turo declare
themselves as providers for the jpeg virtual package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of depending on each provider of cryptodev, make openssl depend
on the virtual package.
This is easy because in both cases the openssl build systems needs the
same configuration options.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
cryptodev-linux and ocf-linux are providers of the cryptodev virtual
package, so they must declare themselves as such.
We do not have any problem for now, as the only consumer (openssl) of
both cryptodev-linux and ocf-linux did not depend on the virtual package
but on each provider. The other consumer is gnutls, but has only a
dependency on cryptodev-linux.
However, openssl can be turned into a proper consumer of the virtual
package, which would trigger the bug.
For the sake of correctness, make both cryptodev-linux and ocf-linux
declare themselves as providers for the cryptodev virtual package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Dosfstools doesn't build with musl only if BR2_PACKAGE_HAS_UDEV is set
due to a missing include for PATH_MAX (limits.h).
Fixes:
http://autobuild.buildroot.net/results/346/346feda6a4a83850dbb62919eb33482302053490
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's remaining from the master-next merge and no longer applies.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported in bug #8206, the mplayer configure script fails to detect
the availability of X11 header/library if the X.org development packages
are not installed on the build machine.
This is due to the logic used by the mplayer configure script, which
looks like this:
for I in $(echo $extra_cflags | sed s/-I//g) /usr/include ; do
if test -f "$I/X11/Xlib.h" ; then
_x11_headers="yes"
So, in other words, it:
1/ Parses the --extra-cflags option, and finds the -I options in there.
2/ Looks in /usr/include
Since $(STAGING_DIR)/usr/include is in the compiler built-in search path
for headers, we currently don't explicitly pass it in --extra-cflags, so
mplayer only looks in /usr/include. If you have X11 headers there thanks
to being installed on your build machine, everything works fine (the
rest of the build logic really uses the headers and libraries of the
cross-compiler). But if you don't have X11 headers in /usr/include, the
configure scripts assumes X11 is not available.
Since fixing the hand-written configure script of mplayer, hosted in a
Subversion repository, is beyond sanity, we simply work around this
problem by passing the appropriate -I$(STAGING_DIR)/usr/include option
in --extra-cflags.
Before this patch, during the configure script:
Checking for X11 headers presence ... no (check if the dev(el) packages are installed)
Checking for X11 ... no (check if the dev(el) packages are installed)
And then, the mplayer binary:
0x00000001 (NEEDED) Shared library: [librt.so.0]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.0]
With this patch, during the configure script:
Checking for X11 headers presence ... yes
Checking for X11 ... yes
And then, the mplayer binary:
0x00000001 (NEEDED) Shared library: [librt.so.0]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libdl.so.0]
0x00000001 (NEEDED) Shared library: [libm.so.0]
0x00000001 (NEEDED) Shared library: [libXext.so.6]
0x00000001 (NEEDED) Shared library: [libX11.so.6]
0x00000001 (NEEDED) Shared library: [libXinerama.so.1]
0x00000001 (NEEDED) Shared library: [libXxf86vm.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.0]
Fixes bug #8206
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The current BR2_GCC_ENABLE_TLS can cause users to make incorrect
choices, and is not very useful. This options allows to decide whether
we pass --enable-tls or --disable-tls to gcc, to enable or disable
support for Thread Local Storage.
Its behavior is:
- The option is default to "y" but only exists if we're using
uClibc/NPTL or glibc.
- When we're using uClibc, the option can be disabled.
So, in practice, this means that currently:
- TLS support is always on for glibc
- TLS support is on by default for uClibc/NPTL, but can be disabled in
the configuration. This is in fact bad and causes the build failure
reported in bug #7424 (this bug is still reproducible on master)
- TLS support is always disabled for uClibc/no-thread and
uClibc/linuxthreads.
- TLS support is always disabled for musl. This does not cause any
build failure, but musl can use TLS support, and therefore be more
efficient. According to
http://www.openwall.com/lists/musl/2012/10/04/1, "Note that if you've
been building gcc with --disable-tls, __thread was already working
but gets emulated (very poorly; it's slow and will abort() if it runs
out of memory) through libgcc.".
So, this commit completely removes the BR2_GCC_ENABLE_TLS and instead
makes the right choice inside gcc.mk directly:
- TLS support enabled for glibc, musl and uClibc/NPTL
- TLS support in other cases, i.e uClibc/no-thread and
uClibc/linuxthreads.
We have intentionally *not* added the option to
Config.in.legacy. Indeed, the new behavior is *exactly* the same as the
older behavior, with the exception of:
- People can no longer disable TLS support in uClibc/NPTL, which was
anyway causing a build failure and therefore was not used.
- TLS support is now enabled on musl, but people using musl already had
BR2_GCC_ENABLE_TLS not set, so they wouldn't get the legacy warning.
Fixes bug #7424.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Back in 2005, in commit
a2c326396a ("update valgrind to the latest
and greatest"), an explicit --disable-tls option was added. More
recently, in commit 31a3f4bd54 ("valgrind:
enable tls support") changed this to be conditional on
BR2_GCC_ENABLE_TLS.
However, the configure script of valgrind is perfectly capable of
detecting TLS support, even in a cross-compilation case: it tries to
compile a program that uses __thread and sees if it works.
Since we're about to modify how BR2_GCC_ENABLE_TLS is handled, we'd
better remove its usage from packages, and valgrind is the only package
using this config option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
