ALSA > 1.1.x are not determined correctly when configuring the library.
A patch, identical to the one used for Qt5, is added to the qt package
to solve this problem.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When uClibc-ng 1.0.17 was released, there was a regression when building
Thumb2-only for a CPU that is capable of running in arm mode (e.g. an
armv7a cpu).
We hastily added a patch to revert the upstream commit, as a stop-gap
measure, waiting for the actual fix.
That actual fix is there, now. :-)
Drop our revert-patch, and add the upstream patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
iproute2 believes that it needs to link with libpthread for its arpd
binary, because "some db implementations require thread". Therefore, our
iproute2.mk explicitly disables the build of arpd when thread support is
not available.
However, the sed expression it uses no longer works. The Makefile used
to look like:
TARGETS = foo baz baz arpd foobar
so replacing " arpd " with a space was working fine. However, the
Makefile got changed in iproute2 to:
ifeq (... berkeleydb available ...)
TARGETS += arpd
endif
i.e, with no space at the end of the line. This made our sed expression
ineffective, causing build issues with no-thread configurations since
arpd was no longer disabled.
To address this, instead of sed-ing the Makefile, we overwrite the
berkeleydb detection of iproute2, by writing to the "Config" file, like
we're doing for other aspects of the package.
Fixes:
http://autobuild.buildroot.net/results/03a37a2372a4c2e438a073e015c49d9e554b86b7/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Traditionally, Buildroot has a default of enabling thread
support. However, with the current construct of the thread choice in the
uclibc package, the m68k and microblaze architecture end up with no
thread support as the default.
In order to avoid having to explicit a more complicated "default" value
for the choice, we take a simple approach: we order the 3 possible
choices by order of "preference", since Kconfig selects the first
selectable option in a choice by default.
So, NPTL is first and is the default when available. Then comes
linuxthreads which only gets selected as the default when NPTL is
available. None is offered as a last choice (in the current
implementation, it is never the default, since all architectures can
have thread support, either through NPTL or linuxthreads).
[Thomas: reworked according to Yann's comment that we could rely on the
Kconfig behavior that selects the first available choice option.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The BR2_PACKAGE_BLKTRACE option "depends on
BR2_PACKAGE_LIBAIO_ARCH_SUPPORTS", but this architecture dependency was
not replicated in the Config.in comment. This commit fixes this
inconsistency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When running ntp it randomly aborts at ntp-4.2.8p8/libntp/recvbuff.c:326
which seems to be a debugging feature. This patch just disables
debugging, it does not fix the root cause of the problem.
Signed-off-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since enlightenment 0.20 uuid.h is always included in e_pixmap.c but
libuuid is checked at configure time only when wayland support is
enabled.
Include uuid.h must guarded by HAVE_WAYLAND.
Fixes:
CC src/bin/src_bin_enlightenment-e_pixmap.o
src/bin/e_pixmap.c:16:18: fatal error: uuid.h: No such file or directory
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
HLS plugin can be built with nettle or libgcrypt or openssl
cryptographic backend. But current dependency on gnutls is incorrect.
It has been working so far because gnutls depends on nettle.
gst-plugins-bad's build system for HLS allows user to choose which
cryptographic backend to use. If that is not specified, it internally
checks for nettle or libgcrypt or openssl in order. If none of the
cryptographic backend is available, HLS plugin gets disabled internally.
Select cryptographic backend according to which cryptographic packages
are available. If both libgcrypt or openssl are not available, choose
nettle by default.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
operf_utils.h defines rmb() for a limited number of architectures, so
add this list to BR2_PACKAGE_OPROFILE_ARCH_SUPPORTS to disable any new
or unsupported architectures.
Doing so, this disable oprofile for m68k which lack of memory barrier
operations.
Remove nios2 dependency since it's not supported by oprofile even if
binutils could be built for nios2.
Fixes:
http://autobuild.buildroot.net/results/1cc761d8a5715d0a2c6eaacfde7e44b225da1b36
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: remove BR2_sh64, use BR2_sh instead of BR2_sh4.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
imx6ul has currently an issue on kernel 4.7 that causes a stall when running
the "reboot" command.
This issue has been reported in the linux-arm-kernel mailing list, but we
don't have a proper fix at the moment.
This problem is not seen when SMP is disabled, so let's disable it for now
until a proper fix becomes available.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Following reports from me of build failures of the GDB simulator for the
Blackfin architecture, Waldemar cooked a
patch (0005-fix-sim-compile.patch) that removes the typedef of SIM_CPU,
because there was a redefinition of this typedef for Blackfin. This was
not causing an issue with recent compilers as redefining the same
typedef is valid with recent compilers, but was causing build failures
with gcc 4.4.x.
However, by removing the common definition of SIM_CPU, this patch broke
the build of the GDB simulator on other architectures, which did not had
an architecture-specific redefinition of SIM_CPU (unlike Blackfin).
The crux of the problem is in a commit from Mike Frysinger, that tries
to refactor the SIM_CPU definition into a common one. Except that it
leaves a redefinition of it for Blackfin. Removing this second
definition however doesn't easily work, due to include ordering
issues. The easiest solution is to simply revert the patch from Mike
Frysinger. This allows to fix the build for all architectures and all
compiler versions.
Fixes:
http://autobuild.buildroot.net/results/3b82c44ee853fab0e0c63881f0705bb659412917/http://autobuild.buildroot.net/results/dafbb93ab38a4285ce42436219d552cceb14828b/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
