Free software library that interfaces with selected Z-Wave PC
controllers, allowing anyone to create applications that manipulate and
respond to devices on a Z-Wave network, without requiring in-depth
knowledge of the Z-Wave protocol
[Peter: also pass DOXYGEN=, add _MAKE_OPTS and use for build+install]
Signed-off-by: Fabrice Fontaine <fabrice.fontaine@orange.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
With some toolchains, using atomics requires to explicitly add -latomic
to the linker flags.
This change adds a patch to pulseview adding this detection and updating
the LDFLAGS when appropriate.
This patch has be sent upstream:
http://article.gmane.org/gmane.comp.debugging.sigrok.devel/2097
Fixes:
http://autobuild.buildroot.org/results/1e3/1e3101261252d5f30fdf842cc99604e4f4c25eef/build-end.log
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit improves the handling of the "atomic stuff" in the libdrm
package. libdrm can either use the atomic intrinsics (4 byte variant)
when available, or otherwise can use libatomic_ops. Note that the
dependency on atomic operations is not from libdrm itself, but only
from some specific DRM drivers only.
Amongst other things, it fixes the build of the libdrm package on
SPARCv8, therefore fixing:
http://autobuild.buildroot.org/results/74dd29b5ea146c320fde80a87a2fc910de9b7f60/
This commit does a number of changes that are all related to each
other:
- Removes the dependency of the Intel DRM driver on
libatomic_ops. The Intel DRM driver builds perfectly fine without
libatomic_ops, as long as 4-byte variant __sync operations are
available, which is always the case on x86 and x86_84 (which are
the only architectures on which the Intel DRM driver can be
enabled).
- Adds an hidden Config.in boolean option
BR2_PACKAGE_LIBDRM_HAS_ATOMIC that allows DRM driver that need
atomic operation to know whether atomic support is available
(either through intrinsics or through libatomic_ops).
- Adds an hidden BR2_PACKAGE_LIBDRM_ENABLE_ATOMIC Config.in option
that DRM drivers that need atomic operation should select to ensure
that the relevant dependencies are selected. It simply selects
libatomic_ops if 4-byte atomic intrinsics are not available. We
could let each DRM driver do this, but having an intermediate
option avoids a bit of duplication.
- Adds a patch that defines AO_REQUIRE_CAS before including
<atomic_ops.h>. This is needed because libdrm uses the
AO_compare_and_swap_full() which is only provided on all
architectures when AO_REQUIRE_CAS is defined. The exact same fix
was done in the erlang package in commit
4a9df29424.
- Adds the dependency on libatomic_ops when the package is enabled,
and passes the necessary CFLAGS on SPARCv8 to make the thing build
properly. The same CFLAGS are passed in the nginx package and bdwgc
package.
Cc: Waldemar Brodkorb <wbx@openadk.org>
Cc: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is basically the same change as in 0515fe4566
("Makefile: pass host PKG_CONFIG_PATH at "make menuconfig" time"). That
commit made sure to pass host PKG_CONFIG_PATH when invoking Buildroot's
own menuconfig program. This change ensures that the same is true for
third party menuconfig programs (i.e. Linux, uClibc and Busybox).
This unbreaks "make {linux,uclibc}-menuconfig" for host platforms which
rely on PKG_CONFIG_PATH to find .pc files (e.g. NixOS). (When Busybox
updates to a more recent Kconfig snapshot, one that uses pkg-config to
find ncurses, "make busybox-menuconfig" will also start working.)
Tested on Ubuntu and NixOS:
$ make qemu_arm_versatile_defconfig
$ make linux-menuconfig
$ make
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This package introduces batman-adv, a kernel module implementation of
the B.A.T.M.A.N. IV and V mesh network routing protocols.
While batman-adv exists in the mainline kernel tree, it can also be
built as an external out-of-tree module. This package adds the
flexibility to chose a more up to date version of the module than exists
in the official tree, and also allows for compilation against kernels
without batman-adv in-tree support.
https://www.open-mesh.org/projects/batman-adv/
Signed-off-by: Christian Stewart <christian@paral.in>
[Thomas:
- remove "default n", since it's the default
- fix indentation of Config.in help text
- license is GPLv2, not just GPL
- remove variable BATMAN_ADV_MAKE_OPTS, name it directly
BATMAN_ADV_MODULE_MAKE_OPTS as this is what is expected by the kernel
module infrastructure.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bump batctl to the latest (2016.1) from 2015.1.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
__P() is used for compatibility with old K&R C compilers. With
ANSI C this macro has no effect.
Unlike for util-linux and ipkg packages where it was easy to remove
each __P() macro, ipsec-tools use it all over the tree and require a
"big" patch to enable musl support.
Since upstream seems not verry active (last release 2014-02-27)
So, disable ipsec-tools with musl based toolchains.
This fixes a compilation error with musl libc because of undeclared
__P.
Fixes:
http://autobuild.buildroot.net/results/42242e3f4485b9e77a916e6fe480c83f70e024e4
While at it, reorder "depends on" and "select" lines in Config.in
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When iptraf-ng is build with musl, it needs _GNU_SOURCE in CFLAGS to define
the content of "struct tcphdr".
iptraf-ng.mk try to add _GNU_SOURCE in CFLAGS but it's not taken into account.
Add it using IPTRAF_NG_CONF_ENV instead of IPTRAF_NG_MAKE_ENV.
Fixes:
http://autobuild.buildroot.net/results/a1b/a1b18f2e3d075d349c19536a7c5553f24b75a323
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 5c67cb1d04 ("linux: use zImage by default on ARM") changed
the default kernel image, but missed to update Zynq defconfigs.
U-Boot on Zynq boards still loads uImage, so BR2_LINUX_KERNEL_UIMAGE
should be defined to generate uImage.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Generate a valid configuration for architectures with
FDPIC and BFLT support.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Added upstream commit to fix compilation when zlib is missing.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It can be a little bit misleading to have no init system...
Add a comment that states the user has to provide his own init system,
either via a package or a rootfs overlay.
It is expected that such a user will know what to provide, so we don't
really need to specify that it should be /init or /sbin/init or any
arbitrary executable pointed to by the kernel command line "init=..."
or anything else...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Removed 0001-cmake-use-the-standard-CMake-flag-to-drive-the-share.patch,
a similar patch was committed upstream:
ea55c8b5c1
Also remove empty line from Config.in.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The mplayer configure script tries to detect the capabilities of the CPU
used by probing the host CPU. This leads to compilation failures if the
target CPU has lesser features, like missing mmx support for
BR2_x86_i686=y:
Checking for CPU vendor ... GenuineIntel (6:58:9)
Checking for CPU type ... Intel(R) Core(TM) i7-3770S CPU @ 3.10GHz
Checking for kernel support of sse ... yes
Checking for kernel support of sse2 ... yes
Checking for kernel support of sse3 ... yes
Checking for kernel support of ssse3 ... yes
Checking for kernel support of sse4_1 ... yes
Checking for kernel support of sse4_2 ... yes
Checking for kernel support of avx ... yes
For this patch I copied most of ffmpeg configure options for x86 CPUs
because mplayer contains its own copy of ffmpeg.
Fixes
http://autobuild.buildroot.net/results/c5a/c5a722607ec9797c317b63b0fd3235608a340c98/
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It may be useful in some scenarios and size growth is marginal at best.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that .py files are globally compiled into .pyc files, we can get
rid of the samba4 specific logic doing this compilation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, each python package (be it the python interpreter package
itself or external python modules) is responsible for compiling its
.py into .pyc files. Unfortunately, this is not ideal as some packages
only install .py files without compiling them into .pyc files. In this
case, if the Buildroot configuration specifies to keep only the .pyc
files, the .py files are removed and lost.
To address this, this commit changes the logic by making the
compilation of .pyc files a global operation: the python interpreter
packages register a target finalize hook that is in charge of
compiling all installed .py files.
The *.pyc generation on a per package basis is disabled in the
python-package infrastructure by passing the "--no-compile" option to
setup.py.
The *.pyc generation for the Python interpreter internal modules is
disabled through --disable-pyc-build configure option.
A small helper script is used to perform the compilation, the purpose
of this script is to abort the compilation process if one of the .py
file cannot be compiled. It has been provided by Samuel Martin and
integrated into this commit.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
[Thomas:
- rework for python 3.5
- integrate Samuel proposal that allows to detect compilation
failures.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit bumpds the version of python-pyftpdlib to fix a
byte-compilation problem occuring with Python 3. The current version of
pyftpdlib contained a file that had mistakenly been added to the
release, and which wasn't Python 3 compliant. The new 1.5.1 version has
been released specifically to address this problem, see:
https://github.com/giampaolo/pyftpdlib/issues/381
Until now, this wasn't causing any problem as a byte-compilation problem
was not a fatal failure. But upcoming commits will make it a fatal
failure, so it needs to be fixed.
Signed-off-by: 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>
As suggested by Samuel Martin, this commit adds the option
--no-run-if-empty xargs option to the "find ... | xargs ..." logic used
in the python and python3 target-finalize hooks to remove py/pyc/pyo
files. This ensures that the command doesn't fail if there are no files
matching the pattern.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Rebase patch 1 in git format, and rebase patch 2 against 1.6.22.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently even if -pie flag is provided to LD dynamic relocations
won't be created. That in its turn will break U-Boot self-relocation
functionality.
This fix resolves mentioned problem.
Note as of today this is a sort of off-the-tree patch right from
our binutils guy but in coming day similar fix will be applied to
upstream binutils as well.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS architecture detection is not accurate and is always detected as
mips64 even if we are using mips64r2 or mips64r6. Due to that, ffmpeg's
build system will pass the -mips64 flag which will conflict with the
-march option that our toolchain wrapper uses, and it will fail to build
showing errors like this one:
error: '-mips64' conflicts with the other architecture options, which
specify a mips64r2 processor
This problem has been already fixed upstream, but we would need to
backport 17 patches plus some changes in the ffmpeg.mk file. This is too
much, so better to just disable ffmpeg for mips64r2 and mips64r6 for the
upcoming Buildroot release.
This commit can be reverted in the next ffmpeg's version bump.
Fixes:
http://autobuild.buildroot.net/results/7fd/7fd8187c0110cdcac622e667f4a81d2db84f11ef/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Using double quotes around TARGET_CC/TARGET_CXX is mandatory, since
they are composed of several words when ccache support is enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Set all file timestamps to prevent the go compiler from rebuilding any
built in packages when programs are built.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
flannel uses the cgo package, so needs a toolchain with thread
support.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The go compiler's cgo support uses threads. If BR2_TOOLCHAIN_HAS_THREADS is
set, build in cgo support for any go programs that may need it. Note that
any target package needing cgo support must include
'depends on BR2_TOOLCHAIN_HAS_THREADS' in its config file.
Fixes build errors like these:
error: #warning requested reentrant code
http://autobuild.buildroot.net/results/42a8d07101d8d954511d1c884ecb66e8d861899e
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Use the newly added HOST_GO_TARGET_ENV variable to pickup the
correct go environment for package builds.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For the convenience of package makefiles define the new
make variables HOST_GO_TOOLDIR and HOST_GO_TARGET_ENV.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The go build system doesn't have the notion of cross compiling, but just the
notion of architecture. When the host and target architectures are different
it expects to be given a target cross compiler in CC_FOR_TARGET. When the
architectures are the same it will use CC_FOR_TARGET for both host and target
compilation. To work around this limitation build and install a set of
compiler and tool binaries built with CC_FOR_TARGET set to the host compiler.
Also, the go build system is not compatible with ccache, so use
HOSTCC_NOCCACHE. See https://github.com/golang/go/issues/11685.
Fixes build errors like these:
host/usr/bin/go: No such file or directory
http://autobuild.buildroot.net/results/6664189a6f3a815978e8d0a1d7ef408ca47e2874/
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Gentoo wiki page is much more informative than the download directory.
This is the official homepage according to top level README.md.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The lirc-tools package fails to build once in a while in the
autobuilders. Some quick analysis of the problematic Makefile.am has
revealed one issue. However, since the issue is difficult to
reproduce, we could only check that the new solution continue to work,
and we're not 100% sure it fixes the entire problem: only the
autobuilders can say, over time.
Supposedly fixes:
http://autobuild.buildroot.org/results/eb47d57de8182d25b1dacbf0ac3726ed20063d04/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a patch available from JamVM's bug tracker to fix the build with
the musl C library. The build was verified with the musl and uClibc C
libraries.
Fixes:
http://autobuild.buildroot.org/results/8292973e9f6f2971d090f02f24d11a31709254cf/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Closes#8911
When the kernel passes single in the command line, this translates
into an init -s option that is suppose to drop into a shell after
the sysinit and before the runlevel.
So, in busybox this is hardcoded - but, in sysvinit using the
sysinit action for the rcS means that it will always be executed
even when trying to get into single user mode for repair.
This change should run rcS in all of the expected runlevels
1-5 and should achieve the desired result compared to the busybox
and still allow a single user shell to get started as expected
before running rcS.
Signed-off-by: Charles Hardin <ckhardin@exablox.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
