1.6.23 tarballs have moved so, while we are at modifying libpng.mk, bump to 1.6.25.
[Peter: add back upstream sha1 hash]
Signed-off-by: Julien BOIBESSOT <julien.boibessot@armadeus.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Adjust some patches to avoid patching the ChangeLog which isn't quite
the same.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Mysql Native Driver has been the default mysql driver since
PHP 5.4, but buildroot was still using libmysqlclient.
Mysqlnd has several advantages such as improved memory management
and the more favorable PHP licensing terms.
(can combine it with proprietary PHP extensions like Ioncube
loader, while libmysqlclient requires commercial licensing if you
link to it and do not fall under their GPL/FOSS license exception)
Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch bumps python pillow to version 3.3.1
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This version includes the patch on execinfo
(commit 775da272719b52bca37b44a40e935a1eb9d10466) so remove
the 0001-add-proper-check-for-detecting-header-execinfo.h.patch file
This version also fixes arc and musl build (ambiguous call to abs and
missing linux/ioctl header):
http://autobuild.buildroot.net/results/b5406ca587592a3bac446d1f1df93d3eb45b96a9 fixed by commit 331cd7d6eef6f9f2658b91e662644d88c31eaf64
http://autobuild.buildroot.net/results/62ec0d348153dff0efd4c1975a9198c17f01f1fa fixed by commit 6ea21db228124565466bf16b0400d40a5eaad30d
Due to DOS line endings, it is easier to reference this beta release
than converting git patches.
The stable release should be released in the first week of October.
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In order to avoid pointless redirects since they're 301.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we moved to ffmpeg 3.x the build and runtime (when patched) problems
have gone away.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Otherwise the one from the host may be used.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
expedite from 1.15 branch doesn't build anymore with efl 1.18 due to
API changes. Since there is no new release or 1.18 scpecific branch,
use the latest commit.
Add a hash file.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: fix hash file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libevas-generic-loaders package is not used anymore, remove it.
Add a legacy entry.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
elementary package is not used anymore, remove it.
Add a legacy entry.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
[Thomas: move the legacy entry at the right place.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
elementary is now provided by efl package, so remove elementary package
dependency.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libevas-generic-loaders is now provided by efl package, so remove
libevas-generic-loaders package dependency.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
elementary is now provided by efl package, so remove elementary package
dependency.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Elementary, evas-generic-loaders and emotion-generic-loaders are now
part of efl 1.18 package [1].
Merge the elementery and evas-generic-loaders package to the efl one.
Rename librsvg option (srvg/libsrvg)
[1] https://phab.enlightenment.org/w/efl_and_elementary_1_18/
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng010.
This engenering build contains different fixes done to TLS and
PIE features. Appropriate custom patches are removed as they have
been added to eng010.
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: Peter Korsgaard <peter@korsgaard.com>
This commit adds a simple patch to the libaio build system that allows
it to be used on static-only configurations. It is probably easier to
fix this than to propagate the !BR2_STATIC_LIBS dependency.
Fixes:
http://autobuild.buildroot.net/results/8c86402bd14a0af1b82e6e07c06531a856dd37c6/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
After fixing the usual sys/cdefs.h and _P stuff the build still fails
because Openswan makes use of GLOB_ functions
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:200:29: error: ‘GLOB_BRACE’ undeclared (first use in this function)
globresult = glob(try, GLOB_BRACE, NULL, &globbuf);
^
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:200:29: note: each undeclared identifier is reported only once for each function it appears in
/home/bernd/buildroot/br4/output/build/openswan-2.6.48/lib/libipsecconf/parser.l:207:41: error: ‘GLOB_NOMAGIC’ undeclared (first use in this function)
globresult = glob(try, GLOB_BRACE|GLOB_NOMAGIC, NULL, &globbuf);
https://github.com/xelerance/Openswan/blob/master/lib/libipsecconf/parser.l#L200https://github.com/xelerance/Openswan/blob/master/lib/libipsecconf/parser.l#L207
[...]
^
which musl does not support:
http://www.openwall.com/lists/musl/2013/09/16/1
Fixes
http://autobuild.buildroot.net/results/70d/70da34c1528b51e92e9e60788f83733d70b33353/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes:
http://autobuild.buildroot.net/results/928be69f90476e6b04be3a1afd3b74112bcac0a0
As mentioned in sha2/README, by default, tinydtls uses u_intXX_t data types
for 8 bit, 32 bit, and 64 bit unsigned integer type definitions. To use
uintXX_t data types as defined by recent ANSI C standards and as included in
the inttypes.h header file, SHA2_USE_INTTYPES_H has to be define at compile
time.
[Peter: reword/simplify]
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When compiling with a toolchain targetted at ucLinux, libserialport's
configure.ac would fail at detecting the target operating system.
As a result, the Linux-specific files were not compiled in that
particular case.
While this commit does not fix any autobuider failure for this package,
it fixes autobuilder failures for other packages, for instance:
http://autobuild.buildroot.net/results/69e/69e43bc171e554cf10f2ad526cebf5e0e524538a/
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, we forcibly tell neon's configure where to look for libexpat.
This means that neon does not search for it, and consequently forgets to
add -lexpat as its Libs.Private in its .pc file. As thus, a static link
against neon forgets to pull in -lexpat (it works for a dynamic link
because libneon has a NEEDED on libexpat).
The reason for specifying the explicit path in this case is lost to
history; neon's configure can correctly find libexpat nowadays.
Fixes:
http://autobuild.buildroot.org/results/884/884746351fc47f4ad19fb3fda7c5e0ee85fcff15/http://autobuild.buildroot.org/results/0c5/0c584522c26640e29980150a87a5b5d8c02e5f8b/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
sconeserver wants to use dlopen(), unconditionally: it does not try to
detect it, and it can't work without it (the code is not conditional).
Fixes:
http://autobuild.buildroot.org/results/e92/e929799366e6f574c7b08d8635b18623afd3e3e1/
[Peter: drop uClibc dependency, adjust commit message]
Reported-by: Matthew Weber <matt@thewebers.ws>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
sconeserver uses pkg-config macros and uses autoreconf, so it
unconditionally needs host-pkgconf.
[Peter: drop host-pkgconf from sub options, update description]
Reported-by: Matthew Weber <matt@thewebers.ws>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The android-tools code is somewhat ugly, and defines its own u64 typedef
becore including kernel headers. Unfortunately, there are specific cases
where that doesn't work properly.
The android-tools code defines u64 as "unsigned long long", which is now
correct in the kernel. However, it used to be a time where u64 was
defined as "unsigned long" on a few 64 bits architecture (at least
PowerPC64 and MIPS64). The kernel headers have introduced a
__SANE_USERSPACE_TYPES__ macro that userspace can define in order to get
the "sane" definition, i.e "unsigned long long" for u64.
Unfortunately, this __SANE_USERSPACE_TYPES__ mechanism only appeared in
3.10 on PowerPC64, and in 3.16 on MIPS64.
Since android-tools is not using the autotools, and there's no easy way
to test types with the C pre-processor, we simply add some more
Config.in dependencies. They are a bit convoluted, but that's what the
dependency really is.
In our autobuilders, this issue was only showing up with an old MIPS64
toolchain that uses 3.9 kernel headers.
Also, since the problem is limited to the "fastboot" tool, the
dependency is only added for fastboot. Both adb and adbd build fine with
this toolchain.
Fixes:
http://autobuild.buildroot.net/results/ce45c995bd6abda6487ae3a11b4f45a7b9b3f8eb/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the bump to libiio 0.7, the systemd service file that used to be
in debian/iiod.service no longer exists. The entire debian/ directory
has been removed from the upstream project:
5d49f58982
Due to this, the installation of this service file fails, and causes
build failures. To address this, we simply remove the installation of
the systemd service file.
Fixes:
http://autobuild.buildroot.net/results/ce2fc81466abd9619aa104c96234d1455de3480d/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bumping to stable version 1.8.4
Signed-off-by: André Hentschel <nerv@dawncrow.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
CVE-2016-4590 - mishandles about: URLs, which allows remote attackers to
bypass the Same Origin Policy via a crafted web site.
CVE-2016-4591 - mishandles the location variable, which allows remote
attackers to access the local filesystem via unspecified vectors.
CVE-2016-4622 - allows remote attackers to execute arbitrary code or
cause a denial of service (memory corruption) via a crafted web site, a
different vulnerability than CVE-2016-4589, CVE-2016-4623, and
CVE-2016-4624.
CVE-2016-4624 - allows remote attackers to execute arbitrary code or
cause a denial of service (memory corruption) via a crafted web site, a
different vulnerability than CVE-2016-4589, CVE-2016-4622, and
CVE-2016-4623.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, a document can not have dependencies, except for the purely
internal ones (like checking asciidoc version, and presence of dblatex).
For our own manual, this will come in handy when we introduce a
generated kconfig snippet, so we can actually make the manual depend on
that snippet being generated first.
For external documents, it can be used to depend on host-packages if
need be (e.g. a custom host packages that generates specific media files
included in the manual).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pkg-utils.mk contains various definitions that are used in the package
infrastructures and packages themselves.
However, those definitions can be useful in other parts of Buildroot,
and are already used in a few places that are not related to the package
infrastructure. Also, $(sep) will be needed early in the Makefile when
we eventually support multiple br2-external trees.
Since this file only contains definitions, we can include it anytime.
So, consider that file to no longer be specific to the package infras:
- move it to support and rename it,
- move a few similar definitions from the main Makefile to that file.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With glibc 2.16, we get following build error when building jack2:
[193/247] cxx: tests/iodelay.cpp -> build/tests/iodelay.cpp.4.o
../tests/iodelay.cpp:171:43: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:171:55: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:172:44: error: 'UINT32_MAX' was not declared in this scope
../tests/iodelay.cpp:172:56: error: 'UINT32_MAX' was not declared in this scope
In glibc 2.17 or older version, Header <stdint.h> defines these macros
for C++ only if explicitly requested by defining __STDC_LIMIT_MACROS.
We can't use <cstdint> since it requires C++11 standard.
Fixes:
http://autobuild.buildroot.net/results/369ce208ffea43dad75ba0a13469159b341e3bf5/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The trousers code uses getpwent_r, which is not available in musl.
Detect the availability of getpwent_r in the trousers build system, and
use it conditionally.
This broke the build of tpm-tools because linking with libtspi.so
failed.
Fixes:
http://autobuild.buildroot.net/results/830fc20c68a0653afa5567edffc2ededc4e45cc6
Runtime-tested by running tpm_version in a chroot and verifying that it
creates a "user.data" file with both the Buildroot-provided CodeSourcery
and Musl toolchains on x86_64.
Signed-off-by: Noé Rubinstein <nrubinstein@aldebaran.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This was not noticed until now because:
1/ The older Blackfin toolchain doesn't have libatomic, so it didn't
provide the atomic operations that protobuf needs, so protobuf was
never built.
2/ The ARM Cortex-M toolchain is static-only, and protobuf requires
dynamic library support.
So it's only with the new Blackfin toolchain, which is based on gcc
6.x (and therefore provides libatomic) and is FDPIC-based (and therefore
has dynamic library support) that this problem appeared.
Since protobuf already has a BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS option,
we use it to add the BR2_USE_MMU dependency (which is architecture
related), which avoids the need to propagate the dependency.
Fixes:
http://autobuild.buildroot.net/results/2c1/2c151e84d7854a810465dc16869023e0ada2d586/
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
[Thomas:
- move the BR2_USE_MMU dependency under
BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS and remove the propagation to
reverse dependencies of protobuf, since they already depend on
BR2_PACKAGE_PROTOBUF_ARCH_SUPPORTS.
- improve commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixing one issue exposed a second one.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The fallback code path didn't work correctly, so fix it.
Fixes:
http://autobuild.buildroot.net/results/3122287ddea1e316a64ccf0d0dc9415bfefebb49/
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The LTO support in the kmsxx package uses the host gcc-ar and gcc-ranlib
instead of the ones from the cross-toolchain. Add a patch that tries to
find the right one based on CMAKE_C_COMPILER.
Fixes:
http://autobuild.buildroot.net/results/16a/16a38a4277dd1152a5955d62cb92f85447791ef3
Possibly also fixes:
http://autobuild.buildroot.net/results/f3c/f3c48da3a9706cd366c0e0a96c3cd0ff959f2a78
(it fails later, possibly because an incompatible host ar)
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Grab the patch from Debian.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The pixman ARM optimized code assumes that ARM instructions are
available. Unfortunately, the configure.ac checks do not detect that the
platform is Thumb-only for Cortex-M builds, so it enables the ARM
optimizations, leading to failures like:
error: /home/test/autobuild/run/instance-3/output/host/usr/arm-buildroot-uclinux-uclibcgnueabi/sysroot/usr/lib/libpixman-1.a(pixman-arm-simd-asm-scaled.o): Conflicting CPU architectures 13/1
When building programs linked with pixman on Thumb-only
architectures. This is due to the fact that some object files in
libpixman-1.a are built for the ARM instruction set.
To resolve this, we give better hints to the pixman configure script
about which ARM optimizations to use: the ARM SIMD optimizations need at
least a CPU that supports ARM instructions, and obviously the ARM NEON
optimizations need NEON support.
Fixes:
http://autobuild.buildroot.net/results/54bee2ce382fcd067965d30f758f9d15514478d9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: add a comment above the --enable-arm-simd option, as suggested
by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of bumping vlc to git master (no vlc 3.x release yet) we use a
patch from deb-multimedia.org which provides the necessary changes for
ffmpeg 3.x support to vlc 2.2, compile-tested using this defconfig:
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_FFMPEG=y
BR2_PACKAGE_FFMPEG_GPL=y
BR2_PACKAGE_FFMPEG_POSTPROC=y
BR2_PACKAGE_FFMPEG_SWSCALE=y
BR2_PACKAGE_VLC=y
This patch can be removed when vlc is bumped to 3.x.
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>
With a small patch, blktrace can work on uClibc: we simply need to link
with librt to use the posix_spawn*() functions.
[Thomas: add reference to upstream commit.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes a number of buffer overflows / use-after-free issues:
http://git.imagemagick.org/repos/ImageMagick/blob/master/ChangeLog
* Prevent buffer overflow in BMP & SGI coders (bug report from
pwchen&rayzhong of tencent).
* Prevent buffer overflow and other problems in SIXEL, PDB, MAP, TIFF and
CALS coders (bug report from Donghai Zhu).
* Prevent buffer overflow (bug report from Max Thrane).
* Prevent memory use after free (reference
https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=30245).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The default boa.conf we install specifies that boa should run under the
nobody group, but we don't have such a group in our default skeleton (and
boa doesn't add it), causing boa to fail to start:
[01/Jan/1970:00:00:10 +0000] No such group: nobody
Instead use the nogroup group, which is presumably what was meant.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
configure.ac has AM_GNU_GETTEXT(), which will enable i18n if a gettext
library is found. For uClibc, it is found if the gettext package has
been built, and it will add -lintl to the link flags. For musl and
glibc, it is always found, in libc itself so nothing is added to the
link flags.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Matthew Weber <matt@thewebers.ws>
Tested-by: Matthew Weber <matt@thewebers.ws>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The source files in the domoticz tarballs have DOS line endings, which
don't appear when fetching the source code from Git. Therefore, a patch
generated from the Git repository doesn't apply directly on the source
code extracted from the tarball.
This commit fixes the patch so that it applies cleanly to the
tarball. Notice that the CMakeLists.txt file is not affected, only the
domoticz.cpp file uses DOS line endings.
While we're at it, we change the patch title prefix from [PATCH 1/1] to
just [PATCH].
Fixes:
http://autobuild.buildroot.net/results/a0539b3551d482411dd4bcd5c9b8c89f77e68475/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump runc to cc29e3dded8e27ba8f65738f40d251c885030a28
This version is required by Docker Engine v1.12.0.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit 6ad14a3687)
Bump docker-engine to the latest stable v1.12.0 from v1.12.0-rc3.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit f892015d78)
domoticz.cpp currently assumes that on GNU/Linux systems header
<execinfo.h> is available. But that is not true. Since it provided by
C library and uClibc can be built without backtrace support. And in
such cases we get following build error.
domoticz-3.4834/main/domoticz.cpp:48:22: fatal error: execinfo.h: No such file or directory
#include <execinfo.h>
^
compilation terminated.
This commit adds patch for detecting presence of <execinfo.h>
and guards code accordingly.
Fixes:
http://autobuild.buildroot.net/results/393/393f839e160b51ca12ac36058718ad2f0c1b50a6/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When commit 031130a4 added the dependency on shared libs for FIT support
in uboot-tools, the dependency of the comment was added exactly as the
dependency of the symbol.
That means the comment is shown when FIT support is possible, and hidden
when it is not, while we want it the other way around...
Fix the dependency.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libbsd installs at least one .pc file that contains a -isystem include
path (-isystem /usr.include/bsd), but -isystem is not munged by
pkg-config, so we end up using /usr/include/bsd which is not suitable
for the target. And breaks big time (see failures, below).
But using libbsd is completely optional. In fact, our lldpd.mk did not
even express the dependency on libbsd, so we may well have had builds
without libbsd.
The functionality brought in by using libbsd is very minor (just setting
the neighbour name in /proc/self/cmdline), so we just make lldpd not use
libbsd at all. There is no --disable-libbsd or such, so we just patch it
out of configure.ac.
Fixes:
http://autobuild.buildroot.org/results/6b7/6b70fa379e834ec71cc260ba6af771b531ca3511/http://autobuild.buildroot.org/results/769/769074c4bb67336ae6679f2c1cd2a8220d2bec24/http://autobuild.buildroot.org/results/c8a/c8a6001f437701ecc75f6c9252935645bda8a8c8/
[...]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit ae0e895054 (nfacct: bump to version 1.0.2, 2016-08-23) we no
longer patch configure.ac.
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since commit b8d446cd56 (libnetfilter_acct: bump to version 1.0.3,
2016-08-23) we no longer patch configure.ac.
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current amd-catalyst options related to the CCCLE tool create the
following Config.in circular dependency:
package/qt/Config.in:134:error: recursive dependency detected!
package/qt/Config.in:134: symbol BR2_PACKAGE_QT_GUI_MODULE is selected by BR2_PACKAGE_AMD_CATALYST_CCCLE
package/amd-catalyst/Config.in:52: symbol BR2_PACKAGE_AMD_CATALYST_CCCLE depends on BR2_PACKAGE_QT_NOPNG
package/qt/Config.in:277: symbol BR2_PACKAGE_QT_NOPNG is part of choice <choice>
package/qt/Config.in:271: choice <choice> contains symbol <choice>
package/qt/Config.in:271: choice <choice> contains symbol BR2_PACKAGE_QT_GUI_MODULE
But in fact, it turns out that selecting BR2_PACKAGE_QT_GUI_MODULE is
not necessary, since we already "depends on BR2_PACKAGE_QT_X11", which
itself selects BR2_PACKAGE_QT_GUI_MODULE. Therefore, to fix this problem
we simply remove the "select BR2_PACKAGE_QT_GUI_MODULE" from the
BR2_PACKAGE_AMD_CATALYST_CCCLE option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, libgtk3 depends on either a full OpenGL stack, or on a
OpenGL-EGL stack provided by mesa3d.
This is because, when using the wayland backend, libgtk3 needs an
OpenGL-EGL stack tht provides the wayland extensions. So far, only
mesa3d would provide those extensions.
But now, those extensions are trickling down to other implementations,
like the Nvidia driver or other (even non-public) implementations.
Change the condition to be on the recently introduced libegl-wayland
option.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
mesa3d implements the EGL extensions for wayland. State so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Wayland requires that an OpenGL/EGL implementation provides a few
extensions, so that wayland servers and clients can exchange buffers.
Currently, only one OpenGL/EGL implementation provides those extensions:
mesa3d.
However, other implementations are catching up, especially the
proprietary NVidia driver, which has as of late introduced those
extensions. Other, non-public implementations may also provide those
extensions.
A lot of wayland-related packages require those extensions, and
currently they have to depend on mesa3d to provide OpenGL/EGL, which
precludes using those packages when a non-mesa3d provider is enabled,
even when that providers implements the necessary extensions.
Add an option to the libegl virtual package, that providers on
OpenGL/EGL can select to state they provide those extensions.
Packages that need those extensions can additionally depend on this new
option, instead of the existing libegl package.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst Linux driver includes OpenCL libraries for GPGPU
computing. This commits adds support to install the binary blobs and ICD
profiles.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst Linux driver includes a graphical controler center for AMD
graphics accelerators, called Catalyst Controler Center. This commits
adds support to install this tool by adding a separated prompt.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
[Thomas:
- As noticed by Yann, fixed the dependency of the comment related to
the Qt PNG functionality.
- Also add the Qt PNG dependency to the BR2_PACKAGE_AMD_CATALYST_CCCLE
option itself, noticed by Yann.
- Add an empty line, also noticed by Yann.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The AMD Catalyst driver includes some command line tools for displaying
specific infos about the GL stack or to test 3D, like fglxinfo or
fgl_gears. This commit adds support to install such tools.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commits adds support for the AMD Catalyst Linux driver 15.9
(15.201.1151). It includes the fglrx kernel module with various fixes
to make it work with at least Linux kernel 4.4 LTS, the userspace OpenGL
stack and the xorg driver module.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas:
- fixup whitespace issues noticed by Yann.
- register AMD_CATALYST_PREPARE_MODULE as a post-patch hook rather than
calling it during the configure step, also suggested by Yann.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now supports nettle as crypto backend too.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since all python modules are now byte-compiled globally this is no
longer necessary.
Signed-off-by: Manuel Vögele <develop@manuel-voegele.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Introduce a new package variable $(PKG)_DL_OPTS. When this variable
is defined, its value is passed to the downloader as options to
the underlying command. Packages can now retrieve archives from server
expecting logins and passwords, use referer url, proxy or specific
options for cloning a repository.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add support for mips64, which is available since musl 1.1.15.
Only gcc 6.x has required support for it. Tested variations of
little/big endian and hard/soft float.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The BR2_TOOLCHAIN_BUILDROOT_GLIBC option is already not selectable on
BR2_sparc, so there is no need to have an additional "depends on
!BR2_sparc" on each of the glibc versions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Older toolchains that use binutils <= 2.23.2 are affected by binutils
bug #14887 (https://sourceware.org/bugzilla/show_bug.cgi?id=14887),
where:
someinstruction [ foo, something ]
is not accepted, due to the whitespace after [ and before ], causing the
following build failures for OpenBLAS:
ARM register expected -- `pld [ r1,#512 ]'
Since we don't have any mechanism to add dependencies on binutils
versions, we work around this problem by patching the code to remove the
problematic whitespaces. As there are many many instances of this in the
ARM assembly code of OpenBLAS, we use a sed expression to make this
modification rather than a patch.
Fixes:
http://autobuild.buildroot.net/results/43e50b480b4aea0fdec745d7875c85377c114cac/
[Peter: use single quotes in sed invocation]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Otherwise the build fail with this error:
configure.in:53: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:95: error: possibly undefined macro: AM_CONDITIONAL
Also, there is a PKG_CHECK_MODULES used for GTK.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream removed use of the GLOB_BRACE glob(3) GNU extension in release 0.9.4
(commits 493857625 and 8bff82ed9c). See
https://sourceforge.net/p/lirc/tickets/174/.
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ncurses buildsystem does not recognise 'uclinux' as being a 'linux',
so it falls back to generic checks, especially when trying to decide
what macros to define. So it misses defining absolutely required macros
when doing widechar, which break the bui,d.
But 'uclinux' is just a 'linux' like any other in this respect.
We fix both aclocal.m4 and the generated ./configure script because
ncurses does not autoreconf correctly (see comment in 0001-*.patch).
Fixes:
http://autobuild.buildroot.org/results/d5c/d5c787d34acbfc0c0c7bd8cc0e15b5bc2460d88a/http://autobuild.buildroot.org/results/fc4/fc4b41fb955c390913a879e0202760347ce29987/
[...too many to list...]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
pinentry currently fails to build with gcc 5.x, because it uses some
functionality from std::string that requires C++11 without passing the
appropriate -std= value. We fix this by passing a proper -std= option
when gcc >= 5.x. Note that this can be removed once pinentry is bumped
to the newest version (currently 0.9.7) because they no longer use
std::string in the Qt part.
Fixes:
http://autobuild.buildroot.net/results/6ea64f692acaebc4d58f3371c632b5121500f17e/
(and many, many similar build failures)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
One-beer-granted-to: Yann E. MORIN <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In commit
5ab751ca44 ("toolchain-buildroot: allow to
build ppc64(le) musl toolchains"), support for building a musl toolchain
for ppc64(le) was added. Since this support only works with gcc 6, some
additional dependencies have been added to the older gcc versions so
that they cannot be selected on ppc64(le)/musl.
Unfortunately, the expression of the dependency was wrong, and leads to
those older gcc versions being non-selectable if you're not using
musl. Indeed, the dependencies look like this:
depends on !BR2_powerpc64 && !BR2_powerpc64le && BR2_TOOLCHAIN_USES_MUSL
So as soon as you're not using musl, BR2_TOOLCHAIN_USES_MUSL is false,
so the entire condition is false, and the gcc version is not available.
Due to this, only gcc 6.x can be selected currently with uclibc or
glibc, which is clearly not the intended behavior.
This commit reworks those dependencies to:
depends on !(BR2_TOOLCHAIN_USES_MUSL && (BR2_powerpc64 || BR2_powerpc64el))
which more clearly expresses what we want:
"We don't want to (have a toolchain that uses musl and (be building
either for PPC64 or PPC64le))"
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>
Otherwise the configure script will probe the distro directories for it
and it may not match what we use, for example fedora uses /etc/pki
instead of /etc/ssl.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This version brings in several bug fixes: one of which partially
addresses Buildroot autobuilder failures for static configurations.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In some older versions of glibc, clock_gettime() is in librt, so we need
to link with librt when clock_gettime() is used. This commit adds a
lirc-tools patch to make sure we link with librt when needed.
Fixes:
http://autobuild.buildroot.net/results/2770360880c9b265c8e019141925e56c35ba22dc/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
While the SourceForge page still exists, it seems to be a bit outdated,
and there is now a much newer Github repository with recent activity, so
mention it as well in the Config.in help text.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The three patches allow to compile applications using TLS emulation from
libgcc or C++ applications.
The patches 892-libgcc-mkmap-symver-support-skip_underscore.patch and
893-libgcc-config-bfin-use-the-generic-linker-version-in.patch fixes how
libgcc is generated, by making the necessary libgcc symbols declared
"GLOBAL", and therefore visible outside of libgcc. This fixes a large
number of undefined reference issues (for either C++ applications or
applications using TLS emulation). This was reported as gcc PR74748.
The patch 894-libgcc-fix-DWARF-compilation-with-FDPIC-targets.patch
allows to build DWARF in FDPIC mode. This patch replaces the older
892-disable-dwarf-bfin.patch, as instead of disabling DWARF support, it
fixes it. This was reported as gcc PR68468.
In order to get C++ working without unresolved symbols, we also need to
disable symbol versioning (--disable-symvers). This is a remaining issue
in gcc which will be investigated at a later point.
Since this commit fixes C++ support in Blackfin, it re-enables the
selection of C++ support for this architecture.
Fixes:
(alsa-lib emutls)
http://autobuild.buildroot.net/results/8544ce58d75820666579db93a25ca5656a8efa8e/
(cairo emutls)
http://autobuild.buildroot.net/results/88b02a5dd5408318941ccbfcea0a9cbaa331500a/
(audiofile c++)
http://autobuild.buildroot.net/results/394e530c5dcd9ccb590eb151aeaadb37d11e0e39/
(assimp c++)
http://autobuild.buildroot.net/results/01f4be126c2d786a5ad7f220c2cf60539888a480/
(bellagio c++)
http://autobuild.buildroot.net/results/ada/ada44228bf13ec05382275bd6571396f5ba2b1f7/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
And drop upstream patch.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With gcc version 6, we get the following error when building jack2:
../tests/iodelay.cpp:170:49: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
jack_latency_range_t capture_latency = {-1, -1};
^
../tests/iodelay.cpp:170:49: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
../tests/iodelay.cpp:171:50: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
jack_latency_range_t playback_latency = {-1, -1};
^
../tests/iodelay.cpp:171:50: error: narrowing conversion of '-1' from 'int' to 'jack_nframes_t {aka unsigned int}' inside { } [-Wnarrowing]
This is fixed by grabbing an upstream commit,
ff1ed2c4524095055140370c1008a2d9cccc5645
Fixes:
http://autobuild.buildroot.net/results/8a8/8a8d533a0f785591fee10f1c09c9294f892ef7f7/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
'std::auto_ptr' is deprecated with gcc-6 but is used in qt4 code.
So we have to build using old C++ standard to prevent build failures.
qt4 is not being developed no more, so unfortunately we can't update
obsolete C++ code and have to add this workaround.
Fixes:
http://autobuild.buildroot.net/results/54172d55f39b2fcfa5b7fb4d4ee01566678babbc/
and also Qt build for ARC.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
binutils-arc-2016.09-eng008 build fails sometimes.
This happens due to the following issue:
binutils configure script has CC variable that stores compiler for
target and CC_FOR_BUILD variable that stores compiler for host.
WARN_FLAGS are verified by the script to be compatible only with CC
compiler but not with CC_FOR_BUILD compiler. Despite this WARN_FLAGS
are passed to both CC and CC_FOR_BUILD compilers. This leads to
unevident errors when cross-compiling. More information you can find
in the binutils mailing list:
https://sourceware.org/ml/binutils/2016-08/msg00117.html
We are going to write a patch for bunutils that fixes the initial
issue. Current patch contains temporary workaround. It should be
deleted after real fix.
Fixes:
http://autobuild.buildroot.net/results/00455b6a8324920ad843d90ce0413451522691a8//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With gcc version 6, we get the following error when building logrotate:
logrotate.c: In function 'postrotateSingleLog':
logrotate.c:1784:5: error: this 'if' clause does not guard... [-Werror=misleading-indentation]
if (!state->doRotate)
^~
logrotate.c:1787:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
if (!hasErrors && log->flags & LOG_FLAG_TMPFILENAME) {
^~
This is fixed by grabbing an upstream commit,
6a36c105587b07ad14fc937f3ee6e2eb402621a2. Once this is fixed, we get:
config.c: In function 'strndup':
config.c:87:10: error: nonnull argument 's' compared to NULL [-Werror=nonnull-compare]
if(!s)
^
cc1: all warnings being treated as errors
make[2]: *** [config.o] Error 1
make[2]: *** Waiting for unfinished jobs....
cc1: all warnings being treated as errors
make[2]: *** [logrotate.o] Error 1
This is due to logrotate providing its own implementation of
strndup(). We could fix it, but it much better to simply use the one
provided by the C library, by fixing the detection method for strndup
availability. This is done in patch
0002-Use-autoconf-checks-for-strndup-and-asprintf.patch.
Fixes:
http://autobuild.buildroot.net/results/6dc2eb22104076920d77425b1e608ef9b9e01c94/
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
[Thomas: replace fix for the nonnull issue with a different one.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The imx-uuc source code uses fork(), so it can only be compiled and used
on MMU-capable platforms. This commit adds the necessary Config.in
dependencies to express this.
Fixes:
http://autobuild.buildroot.net/results/41602c20d4e6a833e72b507792a28b8db74a5f53/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
On some platforms the command 'top -n1 | head' goes very often into an
infinite loop of SIGABRT and double free()s.
Fix by applying a patch from upstream Busybox.
For a detailed explanation of the bug, see
http://lists.busybox.net/pipermail/busybox/2016-August/084555.html
Thanks to Yann for the help in finding this bug.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As tinycbor uses fopencookie() which is not available with the Blackfin
ADI external toolchain (UCLIBC_HAS_GLIBC_CUSTOM_STREAMS is not enabled),
add a dependency on !BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX.
This avoids the following build failure:
src/open_memstream.c: In function ‘open_memstream’:
src/open_memstream.c:105: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘vtable’
src/open_memstream.c:105: error: ‘vtable’ undeclared (first use in this function)
src/open_memstream.c:105: error: (Each undeclared identifier is reported only once
src/open_memstream.c:105: error: for each function it appears in.)
src/open_memstream.c:105: error: expected expression before ‘{’ token
src/open_memstream.c:111: warning: implicit declaration of function ‘fopencookie’
src/open_memstream.c:111: warning: return makes pointer from integer without a cast
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
[Thomas: improve commit message.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
tinycbor 0.3.2 includes the buildroot patch that fixes the installation
with old Makefile used by targets such as blackfin, more details can be
found here: https://patchwork.ozlabs.org/patch/652187
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Latest musl release supports ppc64 architecture (both big endian and
little endian), so this commit adds support for this.
Since musl implements the ELFv2 ABI for both big-endian and
little-endian PowerPC64, we have to force using this ABI on PowerPC64
big endian (normally elfv1 is the default).
Also, only gcc 6.x has the necessary changes to support musl on PowerPC
64, so we restrict the gcc version selection accordingly.
Tested with Qemu for big endian and little endian configurations.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment about the ABI flag in gcc.mk, rework commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ustr Makefile.in (as introduced by the Debian patch we apply), is
probably not parallel-safe:
402 install: install-opt install-dbg
403
404 install-opt: install-dirs install-opt-lib install-common
405
406 install-dbg: install-dirs install-dbg-lib install-common
407
408 install-opt-lib install-dbg-lib install-common: install-dirs
[--SNIP--]
424 install-opt-lib: $(OPT_LIB_STATIC) $(OPT_LIB_SHARED) ustr.pc
425 @echo Installing files
426 install -m 644 -t $(DESTDIR)$(libdir) $(OPT_LIB_STATIC)
427 install -m 755 -t $(DESTDIR)$(libdir) $(OPT_LIB_SHARED)
428 -rm -f $(DESTDIR)$(libdir)/$(OPT_LIB_SHARED_NAME)
429 ln -s $(OPT_LIB_SHARED) $(DESTDIR)$(libdir)/$(OPT_LIB_SHARED_NAME)
430 -rm -f $(DESTDIR)$(libdir)/$(OPT_LIB_SHAREDEV)
431 ln -s $(OPT_LIB_SHARED_NAME) $(DESTDIR)$(libdir)/$(OPT_LIB_SHAREDEV)
432 -rm -f $(DESTDIR)$(libdir)/$(OPT_LIB_SHAREDEV_BSO)
433 ln -s $(OPT_LIB_SHARED_NAME) $(DESTDIR)$(libdir)/$(OPT_LIB_SHAREDEV_BSO)
434 $(LDCONFIG) -n $(DESTDIR)$(libdir)
435 install -pm 644 -t $(DESTDIR)$(libdir)/pkgconfig ustr.pc
436
437 install-dbg-lib: $(DBG_LIB_STATIC) $(DBG_LIB_SHARED) ustr-debug.pc
438 @echo Installing files
439 install -m 644 -t $(DESTDIR)$(libdir) $(DBG_LIB_STATIC)
440 install -m 755 -t $(DESTDIR)$(libdir) $(DBG_LIB_SHARED)
441 -rm -f $(DESTDIR)$(libdir)/$(DBG_LIB_SHARED_NAME)
442 ln -s $(DBG_LIB_SHARED) $(DESTDIR)$(libdir)/$(DBG_LIB_SHARED_NAME)
443 -rm -f $(DESTDIR)$(libdir)/$(DBG_LIB_SHAREDEV)
444 ln -s $(DBG_LIB_SHARED_NAME) $(DESTDIR)$(libdir)/$(DBG_LIB_SHAREDEV)
445 -rm -f $(DESTDIR)$(libdir)/$(DBG_LIB_SHAREDEV_BSO)
446 ln -s $(DBG_LIB_SHARED_NAME) $(DESTDIR)$(libdir)/$(DBG_LIB_SHAREDEV_BSO)
447 $(LDCONFIG) -n $(DESTDIR)$(libdir)
448 install -pm 644 -t $(DESTDIR)$(libdir)/pkgconfig ustr-debug.pc
As Thomas already noticed [0], the two interesting rules above are not
dependent one on the other, so can be run in parallel. So, while one is
doing its rm'n'ln dance, the other can be running an ldconfig, which has
the side effect of creating the missing symlinks. So, we can see this
sequence:
install-opt-lib: install-dbg-lib:
ldconfig
rm -f .../$(OPT_LIB_SHAREDEV) \
`-> symlink(..., .../$(OPT_LIB_SHAREDEV))
ln -s .../$(OPT_LIB_SHAREDEV)
In this case, ldconfig uses the opportunity-window between the rm and
the ln to create the link; so the ln does not work, as the target
already exist.
We fix that by not running ldconfig at all in Buildroot, we just pass
LDCONFIG=/bin/true .
Fixes (hopefully, since I was not even able to reproduce the failure):
http://autobuild.buildroot.org/?reason=ustr-1.0.4http://autobuild.buildroot.org/results/936/93626f55625ed7900c147bfd79ff7802366639b1/http://autobuild.buildroot.org/results/18b/18b6ec537da9e9055f58a8649c0719dc64df1bcf/
[...]
[0] http://lists.busybox.net/pipermail/buildroot/2016-May/161923.html
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Clayton Shotwell <clayton.shotwell@rockwellcollins.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we can drop this patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we can drop this patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we can drop this patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we can drop this patch.
Renumber remaining patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we no longer need to patch it out.
Simplify the patch by removing any hunk removing cdefs.h or the use of
__BEGIN_DECLS/__END_DECLS. However, it must be included when macros it
defines are being used.
Also, renumber patches to guarantee ordering (static patch was added
before big-endian one).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We now always have a sys/cdefs.h, so we can drop this patch.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
rpcbind uses the __P() macro defined in sys/cdefs.h but does not
includes it explicitly, relying on the glibc behaviour to include it
from its own headers.
But this macro does nothing but expands as its argument. In the past,
it did provide support for pre-ANSI compilers that did not support
function prototypes. Those are now gone, and glibc provides this macro
for legacy code.
Patch out the use of __P() altogether.
Fixes:
http://autobuild.buildroot.org/results/346/346c5b562c244ddb039db2f86f71d670a01ed9ce/http://autobuild.buildroot.org/results/d77/d77454265c45539178c008c5d92509c441447675/
and numerous such autobuild failures
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
musl provides neither sys/queue.h nor sys/cdefs.h. Those two headers are
however quite widely used in a lot of packages (though they should at
least not use cdefs.h which is only full of mostly-legacy macros, and
which is mostly an internal header of glibc and was never really meant to
be exposed to, and used by packages).
But we don't live in an ideal world, so a lot of packages break when
those two headers are missing.
We already took care of sys/queue.h with the netbsd-queue package. But
the need for cdefs.h is getting more and more pressing.
We rename the netbsd-queue package into musl-compat-headers, and we
make it install sys/queue.h (from NetBSD) and sys/cdefs.h (a minimalist
one we bundle in Buildroot). We can't use the cdefs.h from NetBSD
because it includes machine-dependent headers; instead we bundle a very
minimalistic one, that covers only what we need.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The dependency on kernel headers >= 3.14 was added by
b9fa6c00b1 since
librttest requires __NR_sched_setattr and
__NR_sched_getattr syscalls (rt-sched).
But these syscalls have just been added to kernel 4.8 for SH4.
Fixes:
http://autobuild.buildroot.net/results/67fc16366717f34df492683a14ecd23376e23110
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When used with GCC 6 ABIv4 is used.
Missing this patch leads to numerous runtime errors.
The patch has already been accepted in uclibc-ng:
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3e40f9669279f005f7154892539166f5081fbcb2
So the patch should be removed after update to a new version of uclibc-ng.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Elfutils program names collide with binutils' binaries. By default
applications provided by elfutils are prefixed with "eu-", but in
Buildroot that setting is overridden by pkg-autotools.
The option in pkg-autotools rules was added to avoid including a target
triple in some packages as a prefix, so restore elfutils default
behaviour by adding a "eu-" program-prefix.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[Thomas: add comment in the .mk file explaining why we have a custom
program prefix, as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since [1] <package>-reconfigure target is broken.
$ make elementary-reconfigure
Applying buildroot-libtool-v2.4.4.patch using patch:
Error: duplicate filename 'buildroot-libtool-v2.4.4.patch'
Conflicting files are:
already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch
to be applied : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch
When a package uses AUTORECONF, the libtool patch can be applied a
second time on the same ltmain.sh in the same directory as the
<package>-reconfigure target is called. This is not a problem since
autoreconf will overwrite the previously patched files. But with the
check introduced by [1], apply-patches.sh throw an error when the
package is reconfigured since the libtool patch is already present in
.applied_patches_list.
In addition to this, the .applied_patches_list file generated by
apply-patches.sh while patching ltmain.sh is not in the top-level
package source directory. Instead a duplicated .applied_patches_list
is generated beside the patched ltmain.sh which can be in a
subdirectory.
As noticed by Arnout Vandecappelle [2], the apply-patches.sh script
doesn't bring anything for the libtool patches.
"apply_patches.sh does the following:
* It handles directories -> not needed here.
* It handles compressed patches and tarballs -> not needed.
* It handles series files -> not needed.
* It handles errors in case of multiple patches -> not needed since
it's only one patch.
* It detects errors based on *.rej files -> not needed since it's only
a single patch so patch exit code is OK.
* It writes the patch list -> for libtool, this is quite silly because
it will be written in the directory where ltmain.sh is found, not in the
top-level directory, so you have these patch lists spread over the
source tree."
So use patch directly rather than apply-patches.
[1] 1924159814
[2] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It uses PTHREAD_PRIO_INHERIT, which isn't available in Linuxthreads.
Fixes:
http://autobuild.buildroot.net/results/455465c332d291929c1612d18a9e7448d9c76e73/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: drop comment about the NPTL dependency being related to
alsa-lib, as it's not the case. Suggested by Baruch.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When available, libconfuse will use the libintl provided by the gettext
package.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
[Thomas: make it really an optional dependency.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
CVE-2016-6489 - RSA code is vulnerable to cache sharing related attacks.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
check and valgrind are optional depenencies of lldpd, so we must depend
on them when either is enabled.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes CVE-2016-6313: An attacker who obtains 580 bytes from the standard RNG
can trivially predict the next 20 bytes of output.
Add cryptographically secure sha256 hash.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes CVE-2016-6316: Bug in the mixing functions of Libgcrypt's random number
generator. An attacker who obtains 4640 bits from the RNG can trivially
predict the next 160 bits of output.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In configure script there are some tests that are looking for
a suitable compiler. For this purpose script tries to compile
and link some C++ code that is hardcoded in the body of script.
The problem is that only linker flags ($LDFLAGS) are passed to the
compiler when the script is compiling test code. Therefore some
necessary command line options can be lost and this would lead to
errors.
This exactly happens to ARC:
1. -matomic option is lost as it compiler option,
2. test code compilation fails,
3. the script decides not to use arc-buildroot-linux-uclibc-g++,
4. scipt checks host compiler (x86_64-linux-gnu-g++ in your case),
5. package is being built for x86_64, not for ARC.
About last 2 steps - I don't know why configure script should try
to build stella for host machine. As for me an error should be
raised and a build should be stopped. But this is up to stella
developers.
Current patch adds compiler options ($CXXFLAGS) when compiling
test code in configure script.
Fixes stella build for ARC, e. g.:
http://autobuild.buildroot.net/results/c23/c23d655137b1c1825b1da69b18307c6a1d4b23b8//
[Peter: s/CPPFLAGS/CXXFLAGS/]
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
