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>
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>
The default Blackfin processor in Buildroot isn't supported by
gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors
for internal toolchain users.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
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>
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>
As pointed out in bug #9161, we don't always have an inittab file (if
systemd or no init is used), so the post build script should only try to
tweak it if present.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As pointed out in bug #9161, we don't always have an inittab file (if
systemd or no init is used), so the post build script should only try to
tweak it if present.
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>
The reproducible build is only in its infancy; it is far from being
complete.
As such, move it to the "advanced" build sub-menu, where it belong for
now...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
BR2_BINFMT_FLAT_SEP_DATA can be used to create XIP userland and works fine
for m68k. Unfortunately a lot of basic packages as pcre are not compileable
because of a CPU or hardware limitation. The reason for failing are very
big functions used in the libraries or application code.
Typical errors are:
Fatal error: Tried to convert PC relative branch to absolute jump
or
error: value -yyyyy out of range
Add kernel patch from 4ec5542679 to make
BR2_BINFMT_FLAT_ONE compiled firmware work fine.
Fixes:
http://autobuild.buildroot.net/results/20b/20b1586757450d6aad8583ad7a787a7ca11acef1/http://autobuild.buildroot.net/results/d31/d311955ada1ffcd7f69e82965c8fe33eabe488cd/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add comment in Config.in file about sep-data existing on m68k,
but being disabled due to build issues with numerous packages.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Greg Ungerer fixed recently a bug in the Linux kernel, which
allows to use one memory region again.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: cherry-picked from next to master, in order to be able to use
BR2_BINFMT_FLAT_ONE by default on m68k, since BR2_BINFMT_FLAT_SEP_DATA
causes too much problems.]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The pc_x86_64_efi reference defconfig is targeted towards an EFI
environment but the kernel which comes with it does not enable EFI
support by default.
Booting this defconfig without kernel EFI support on a qemu virtual
machine with EFI firmware resulted in no output to tty1 or ttyS0.
Enabling EFI support in the kernel fixed this and seems saner for an EFI
reference Buildroot defconfig.
Adding CONFIG_EFI to board/pc/linux-extras.config also affects
pc_x86_64_bios_defconfig which doesn't require it, however it was
observed that the extra overhead is small and so this is preferred
rather than having a separate config file.
This was tested with qemu 2.6.0 running with kvm enabled and firmware
EFI v2.60 by EDK II. Also built and verified bios defconfig on the same
setup but with BIOS firmware instead.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
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>
The instructions listed sdcard.img as output image name but
board/pc/genimage-*.cfg generate it named as disk.img instead.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
