This reverts commit a0aa7e0e17 and reworks
the code to fix a major and potentially catastrophic bug when the
following conditions are met:
- The user has selected a "known toolchain profile", such as a Linaro
toolchain, a Sourcery CodeBench toolchain etc. People using "custom
toolchain profile" are not affected.
- The user has enabled BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y to
indicate that the toolchain is already locally available (as
opposed to having Buildroot download and extract the toolchain)
- The user has left BR2_TOOLCHAIN_EXTERNAL_PATH empty, because his
toolchain is directly available through the PATH environment
variable. When BR2_TOOLCHAIN_EXTERNAL_PATH is non-empty, Buildroot
will do something silly (remove the toolchain contents), but that
are limited to the toolchain itself.
When such conditions are met, Buildroot will run "rm -rf /*" due to
TOOLCHAIN_EXTERNAL_INSTALL_DIR being empty.
This bug does not exist in 2016.05, and appeared in 2016.08 due to
commit a0aa7e0e17.
Commit a0aa7e0e17 removed the assignment
of TOOLCHAIN_EXTERNAL_SOURCE and TOOLCHAIN_EXTERNAL_SITE to empty, as
part of a global cleanup to remove such assignments that supposedly
had become unneeded following a fix of the package infrastructure
(75630eba22: core: do not attempt
downloads with no _VERSION set).
However, this causes TOOLCHAIN_EXTERNAL_SOURCE to be non-empty even
for BR2_TOOLCHAIN_EXTERNAL_PREINSTALLED=y configuration, with the
following consequences:
- Buildroot downloads the toolchain tarball (while we're saying the
toolchain is already available). Not dramatic, but clearly buggy.
- Buildroot registers a post-extract hook that moves the toolchain
from its extract directory (output/build/toolchain-external-.../ to
its final location in host/opt/ext-toolchain/). Before doing this,
it removes everything in TOOLCHAIN_EXTERNAL_INSTALL_DIR (which
should normally be host/opt/ext-toolchain/).
Another mistake that caused the bug is commit
b731dc7bfb ("toolchain-external: make
extraction idempotent"), which introduce the dangerous call "rm -rf
$(var)/*", which can be catastrophic if by mistake $(var) is
empty. Instead, this commit should have just used rm -rf $(var) to
remove the directory instead: it would have failed without consequences
if $(var) is empty, and the directory was anyway already re-created
right after with a mkdir.
To address this problem, we:
- Revert commit a0aa7e0e17, so that
_SOURCE and _SITE are empty in the pre-installed toolchain case.
- Rework the code to ensure that similar problems will no happen in the
future, by:
- Registering the TOOLCHAIN_EXTERNAL_MOVE hook only when
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y, since moving the toolchain is
only needed when Buildroot downloaded the toolchain.
- Introduce a variable TOOLCHAIN_EXTERNAL_DOWNLOAD_INSTALL_DIR which
is the path in which Buildroot installs external toolchains when it
is in charge of downloading/extracting them. Then, the
TOOLCHAIN_EXTERNAL_MOVE hook is changed to use this variable, which
is guaranteed to be non-empty.
- Replace the removal of the directory contents $(var)/* by removing
the directory itself $(var). The directory was anyway already
re-created if needed afterwards. Thanks to doing this, if $(var)
ever becomes empty, we will do "rm -rf" which will fail and abort
the build, and not the catastrophic "rm -rf /*".
Reported-by: Mason <slash.tmp@free.fr>
Cc: Mason <slash.tmp@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
(cherry picked from commit b171466c44)
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>
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>
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>
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>
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>
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>
