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>
This reverts commit 73da2ff6f7.
The reason for adding support for a local location was to be able to do
development on the Linux kernel source tree on a local directory rather
than have to clone it for every build.
We already have a mechanism for that, it's called override-srcdir. It's
been available since September 2011, more than a year before this patch
was committed.
Otherwise, we're going to be adding support for local sources in other
packages. First was U-Boot as submitted by Adam. But what next? We can't
have such support for all packages, especially since override-srcdir
does the job.
Besides, using a local source tree makes the build non-reproducible, so
we don't really want to have this in a .config (or defconfig).
We only handle the boolean option in legacy, as there is nothing we can
do with the directory path.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Rafal Fabich <rafal.fabich@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Adam Duskett <aduskett@gmail.com>
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>
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>
Some of those directories will be needed even during configuration, like
BUILD_DIR, where we'll store the generated kconfig snippet.
So, move the rule to create them outside the BR2_HAVE_DOT_CONFIG block.
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>
[Thomas: fixup commit log, as noticed by Romain Naour.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, all configurators depend on generating the out-of-tree
Makefile wrapper.
In an upcoming patch, we'll need to also generate a kconfig fragment,
so it will have to kick in before we run the configurators.
Introduce a new intermediate "prepare-kconfig" rule, so we can
commonalise the dependencies of the configurators. Move the dependency
on the Makefile wrapper to that new intermediate rule.
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>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: mark prepare-kconfig as a phony target.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The code for both cases is exactly the same, and only differs in the
location where defconfig files are looked for.
We use an intermediate macro to generate the corresponding rules,
because directly generating the rules is ugly and needs lots of escaping
and double-dollar-ing for the $(eval ...) and $(foreach ...) calls to
play nicely together.
Furthermore, that will be tremendously useful when we support multiple
br2-external trees.
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>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: move comment outside of the make target, so that it isn't
displayed on stdout when loading a defconfig.]
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>
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>
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>
As recently discussed on lwn.net: https://lwn.net/Articles/695478/
The kernel has special behaviour for uid/gid 65534:
1. The kernel maps UIDs > 65535 to it when some subsystem/API/fs
only supports 16bit UIDs, but a 32bit UID is passed to it.
2. it's used by the kernel's user namespacing as the internal UID
that external UIDs are mapped to that don't have any local mapping.
3. It's used by NFS for all user IDs that cannot be mapped locally if
UID mapping is enabled.
Most distributions already map (or are in the progress of changing)
nobody/nogroup to the 65534 uid/gid, so lets do so as well.
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>
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>
