kodi needs CWIID_MESG_BALANCE
https://github.com/xbmc/xbmc/blob/Krypton/tools/EventClients/Clients/WiiRemote/CWIID_WiiRemote.cpp#L106
It was added after the last cwiid release, which took place 2009:
2174214bc2
Instead of adding another 20k-sized patch we switch to the upstream
github repo and bump to its HEAD commit, dating back to 2010.
By doing this we can remove two patches which were applied upstream:
0001-fix-link-options-for-as-needed-90.patch
6af6786165
0002-Update-for-BlueZ-changes.patch
c5dd7d4a9a
The remaining patches were renumbered.
This patch is needed for the upcoming Kodi version bump which also adds
optional cwiid support.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently the buildroot website is not leveraging common
techniques to have a better loading speed (browser caching,
gzip compression, deflating).
This commit provides an .htaccess files with all the needed to
enable mentioned features. This .htaccess only works if the
webserver has deflate, expires and headers modules enabled.
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
memtool allows one to read and write memory mapped registers via /dev/mem.
The commands are inspired by the respective commands of the barebox
bootloader. This is handy during driver development to inspect and modify
register settings. It can also be used to modify regular files and
character devices (e.g. to paint to /dev/fb0).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Thomas: add entry to DEVELOPERS file.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 4422eca2d4.
We now have a workaround for the RPATH issue introduced in 3.7, so we
can use it again.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
mpd package fails for both internal and external ARC toolchain as check
for pthread support fails. Such checks fails because _REENTRANT flag is
not defined in gcc even when -pthread is passed.
So we add patch to gcc that defines _REENTRANT on ARC when -pthread is
passed.
Also it disables mpd package for external ARC toolchain as it fails due
to the same issue.
This patch should be reverted as soon as the patch for GCC becomes a
part of ARC toolchain.
Fixes:
http://autobuild.buildroot.net/results/7d7/7d70b62ad996830fbeca46dffcc7a1dc030e575d//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 1ffcf364b6 updated cmake to 3.7.0,
which requires selecting the libuv package. At the time, the libuv
package only depended on BR2_TOOLCHAIN_HAS_THREADS. However, later on,
it was changed in master to depend on BR2_TOOLCHAIN_HAS_THREADS_NPTL, a
change which was not taken into account in the cmake 3.7.0 bump that was
merged in the next branch.
Due to this, builds of cmake is attempted on architectures that don't
provide NPTL thread support, causing a build failure. This commit fixes
that by adjusting the dependency.
Fixes:
http://autobuild.buildroot.net/results/16a5e1cbb57c0124537c4f3dc0807ba1eaa975ec/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libuv is now a required dependency.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The handling of RPATH in cmake-3.7 has changed drastically, causing a
slew of build failures dues to libraries from the host being pulled in:
- domoticz : http://autobuild.buildroot.org/results/fd0/fd0ba54c7abf973691b39a0ca1bb4e07d749593a/
- freerdp : http://autobuild.buildroot.org/results/5d4/5d429d0e288754a541ee5d8be515454c5fccd28b/
- libcec : http://autobuild.buildroot.org/results/3f3/3f3593bab7734dd274faf5b5690895e9424cbb89/
- and so on...
The bug was reported upstream [0], which dismissed it altogether [1] as
being expected behaviour, quoting:
I don't think there is anything wrong with that change on its own.
It merely exposed some existing behavior in a new case.
Instead, upstream suggested in that same message that a platform
definition be used instead, quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them as needed for the target platform.
So here we are doing so:
- we add a new platfom definitions that inherits from the Linux one,
then overrides the problematic settings;
- we change our toolchain file to use that platform instead;
- we tell cmake where to find additional modules, so that it can find
our custom platform file.
This has been tested to work in the following conditions:
- pre-installed host cmake, versions 3.5.1 (Ubuntu 16.04) and 3.7.2
(manually built)
- internal cmake, versions 3.6.3 (the current version as of this
patch) and 3.7.2 (with the followup patches).
Thanks to Jörg, Ben and Baruch for the help investigating the issue.
Special thanks to Jörg for handling the discussion with upstream and
pointing to the relevant messages! :-)
[0] http://public.kitware.com/pipermail/cmake/2017-February/064970.html
[1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
To be noted: Thomas suggested we set these directly in the toolchain
file. Unfortunately, wherever we put those settings in the toolchain
file, this does not work.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Baruch Siach <baruch@tkos.co.il>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
GNU classpath builds fine on sparc and sparc64 architectures. So
we allow building it there to be consistent with the naming of
BR2_PACKAGE_CLASSPATH_ARCH_SUPPORTS.
Signed-off-by: Marcus Hoffmann <m.hoffmann@cartelsol.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As reported in this bug report [1], altivec support in SDL break
arbitrary C++ code.
Issue reported by test-pkg script while testing supertux package:
error: could not convert 'true' from 'bool' to '__vector(4) __bool int'
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi/?bug=770670
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The iso9660 generation for grub2 assumes that grub-eltorito.img is
available. However, this image is only available for the i386-pc target
(i.e. legacy BIOS). An EFI-bootable iso9660 requires a different layout.
Since we currently can't generate the EFI-bootable iso9660 layout,
require the i386-pc target to be selected in grub.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reported-by: arnaud.miche@orange.com
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Set ENABLE_CUSTOM_COMPILER_FLAGS to OFF to disable custom flags, in
particular -fstack-protector-strong which depends on
BR2_TOOLCHAIN_HAS_SSP
Fixes:
http://autobuild.buildroot.net/results/cfcf3bc8066159dfddd1786954d78e8527858f2f/
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ncftp build process tries to build and run a small program called
ccdv to beautify the build process output. If it manages to build and
run it, then it uses it.
Unfortunately, this doesn't work well when the target architecture is
close to the host architecture, but not exactly the same. Because both
architectures are close to each other, the test run of ccdv succeeds,
but real use of ccdv during ncftp build process causes an Illegal
instruction issue.
This for example happens with the CodeSourcery AMD64 toolchain, on a
build machine running an i7-4600U, and has been detected in the
autobuilders since the CodeSourcery AMD64 toolchain was upgraded at
the end of January:
http://autobuild.buildroot.net/?reason=ncftp-3.2.6
The issue was also reported by Christopher Arguin back in July 2016:
http://lists.busybox.net/pipermail/buildroot/2016-July/168026.html
and at the time, we identified that simply disabling the ccdv tool, by
passing --disable-ccdv, was enough to solve the issue. But Christopher
never submitted the patch, so the problem remained unfixed.
Therefore, we pass --disable-ccdv to the configure script, which
fixes:
http://autobuild.buildroot.net/results/6eadad0e879ca70bb07b13b4196d42c64b11699f/
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>
This package fails when building with ARC external toolchain
Marking this with special comment "# ARC toolchain issue" as the package
is to be enabled as soon as the issue with the ARC toolchain is
resolved.
Fixes:
http://autobuild.buildroot.net/results/fb6/fb677a917545adee321bdcd2c2519c81326448c4//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This package fails when building with ARC external toolchain
Marking this with special comment "# ARC toolchain issue" as the package
is to be enabled as soon as the issue with the ARC toolchain is
resolved.
Fixes:
http://autobuild.buildroot.net/results/28a/28a92049a6ceef005787c5779f77ecf3fe8ad642//
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit e482ebf51d attempted to fix the
installation of qt5quickcontrols by only installing the PrivateWidgets
directory for the 5.8.0 version.
However, the availability of PrivateWidgets has nothing to do with the
version; in both 5.6.2 and 5.8.0, the installation is gated by the
following statement in src/src.pro:
qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets
i.e. it is installed when both the Quick and the Widgets module are
available. The Widgets module is controlled by Buildroot's
BR2_PACKAGE_QT5BASE_WIDGETS symbol, the Quick module is controlled by
Buildroot's BR2_PACKAGE_QT5DECLARATIVE_QUICK. The qt5quickcontrols
package selects BR2_PACKAGE_QT5DECLARATIVE_QUICK so it is not really
needed to include it in the condition. However, it is theoretically
possible to build this package without QtQuick. Also, adding this
condition makes it consistent with src.pro.
Note that commit e482ebf51d introduces a
second fix (not mentioned in the commit message): for version 5.6.2, the
Layouts directory is installed, but in 5.8.0 this directory doesn't
exist any more. Therefore, a separate condition on the version is still
needed.
Fixes:
http://autobuild.buildroot.net/results/1ff3e9ad4ba518d0a37f9fc12038bf9020f28094
Cc: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit a75ab1fc1d ("package/classpath:
Don't depend on jamvm"), we removed the dependency of classpath on
jamvm. Since jamvm is only available for a reduced set of architectures,
classpath could until this commit until be built on those architectures.
However, now that this dependency has been removed, classpath can
potentially be built for all architectures supported by Buildroot, even
though it doesn't support all of them.
Since adding support for additional architectures in classpath doesn't
make much sense, because classpath is in Buildroot only usable with
JamVM anyway, and JamVM is only available for a small set of
architectures, this commit simply makes classpath available on the
architectures that it supports.
By doing so, it also removes the or1k support patch which was added by
commit f12a146f81, since anyway or1k is
not supported by JamVM.
Fixes:
http://autobuild.buildroot.net/results/55eb89f89e96b94a821778bc18ed844af08b7460/
(classpath on microblaze)
http://autobuild.buildroot.net/results/279dd731bd9ecf5f9d54bda3715caeaa7cbcdbb3/
(classpath on nios2)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On PowerPC64(le), we patch all configure scripts. Due to this, the
version.texi in OpenOCD files gets regenerated, and then since it has
a newer date than openocd.info, openocd build system rebuilds the
documentation. Unfortunately, this documentation rebuild fails on old
machines.
We work around this by faking the date of the generated version.texi
file, to make the build system believe the documentation doesn't need
to be regenerated.
Fixes:
http://autobuild.buildroot.net/results/3cbe65a46e75b8e67846d593884c96df97dec7a4
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake-3.7 has a bug in how it handles rpath, linking with libraries from
the host.
Until we completely understand the issue, just blacklist cmake-3.7.
The issue has been reported upstream:
http://public.kitware.com/pipermail/cmake/2017-February/064970.html
Reported-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Ben Boeckel <mathstuf@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 68cebedeb9 ("assimp: work around
gcc bug on SuperH"), a work around was added to make the package build
with gcc on SuperH. The condition included a test on the gcc version,
which was mistakenly done on the host gcc version, while a test on the
target gcc version was intended.
Thanks to Peter Korsgaard for spotting the issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit enables PAM support in systemd if BR2_PACKAGE_LINUX_PAM is
set. Some essential config files are not installed without the
--enable-pam option.
Signed-off-by: James Balean <james@balean.com.au>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gcc versions earlier than gcc 6.x fail to build assimp on SuperH when
static linking:
AssxmlExporter.cpp:623:1: error: unable to find a register to spill in class 'GENERAL_REGS'
It's the combination of -Os and *not* having -fPIC that makes gcc
fail, which explains why configurations with dynamic linking work
fine.
-Os -fPIC -> works
-Os -> fails
-O2 -fPIC -> works
-O2 -> works
Therefore, as a workaround, we are forcing the use of -O2 on SuperH
when the gcc version is older than gcc 6.x and we're statically
linking.
Fixes:
http://autobuild.buildroot.net/results/ec88aa8118179e30e24603cc45292047dca19216/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
BR2_TOOLCHAIN_EXTERNAL_BLACKFIN_UCLINUX has been removed in commit
311bc137da ("toolchain: kill ADI
Blackfin toolchain"), so this "depends on" is useless.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Override gcc optimization flags with -O0. The workaround is not required
for gcc6 anymore, so we take this into account into our condition.
Fixes:
http://autobuild.buildroot.net/results/a318f0838a6a602046e719103ac81965c0084d52
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: add gcc 6.x condition.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MPlayer doesn't support OpenRISC:
The architecture of your CPU (or1k) is not supported by this configure script
It seems nobody has ported MPlayer to your OS or CPU type yet.
so disable it on this architecture.
Fixes:
http://autobuild.buildroot.net/results/47207dfd10ff6e5ec4ccdcf8454aaf5f408ad1e3/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The python-libconfig package fails to build with musl with very weird
errors coming all the way from Boost Python, which nobody ever
bothered to fix. It's time to disable this package on musl to avoid
the repetitive build failures.
Fixes:
http://autobuild.buildroot.net/results/f0f6cdc8c38c024772615d5e677b0f4ad63ef7ec
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The libuv library uses __sync atomic built-ins:
$ readelf -a -W output/target/usr/lib/libuv.so.1.0.0 | grep __sync
122: 00000000 0 NOTYPE GLOBAL DEFAULT UND __sync_val_compare_and_swap_4
but this is not currently taken into account in the libuv package,
causing some build failures in packages using libuv as an optional
dependency, such as janus-gateway and mosquitto.
Therefore, this commit updates the libuv package with this additional
dependency. The reverse dependencies of libuv are also updated: luv, luvi
and moarvm.
Fixes:
- http://autobuild.buildroot.net/results/bdaa67d763c0d8d377a04529c74f73bee7d4ccef/
(janus-gateway)
- http://autobuild.buildroot.net/results/2bc84ba2d1167018e2d48e5183ead22b6425dcf5/
(mosquitto)
[Peter: drop cmake changes after cmake revert]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
htop wants to use backtrace() support from the C
library. Unfortunately, with old uClibc versions such as the one we
use for the ARC architecture, the backtrace() implementation is in
libubacktrace. In addition, this implementation needs dladdr()
support, which is in libdl, not available when static linking.
Since this problem no longer exists in more recent versions of uClibc,
we simply special case the ARC+static linking case, and make the
configure script believe that <execinfo.h> is not available.
Fixes:
http://autobuild.buildroot.net/results/cdea351fad7a0f61ddec3e6a141da8da0523a902/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Buildroot manual documents that <pkg>_CONF_ENV is passed in the
environment when calling cmake during the configure step. However, the
actual implementation in pkg-cmake passes HOST_<pkg>_CONF_ENV when
configuring the host variant of a cmake package, but does not pass
<pkg>_CONF_ENV when configuring the target variant of a cmake package.
This commit fixes that by passing <pkg>_CONF_ENV in the environment as
expected. It should not cause any behavior change, because this
feature is in fact not used by any package in upstream Buildroot:
$ grep CONF_ENV $(git grep -l cmake-package package/)
package/pkg-cmake.mk:$(2)_CONF_ENV ?=
package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
package/pkg-cmake.mk: $$($$(PKG)_CONF_ENV) $$(BR2_CMAKE) $$($$(PKG)_SRCDIR) \
This issue was reported by Olivier <ovalentin@awox.com> as bug #9616.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit 1ffcf364b6.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit d96fafc3d3.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit b754237520.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cmake 3.7 causes serious regressions in some cmake-based packages,
related to how RPATH is handled.
This reverts commit f8a6990c92.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jörg Krause <joerg.krause@embedded.rocks>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
DirectFB is written in C++, but can be linked to by a C library or
program.
When doing shared link, this is fine because the linker gets help from
the DT_NEEDED flags and knows what libraries to pull in during the link.
However, during a static link, the linker does not get such help.
Properly fixing this would require that there is support in pkg-config
and autotools to specify that the C++ runtime must be linked. Alas there
is no sush support. The only option is to add -lstdc++ to the
Libs.Private field in directfb.pc. But this is not upstreamable, because
there are other C++ runtimes in the wild (e.g. -lc++ from llvm/clang).
However, DirectFB in a static scenario is probably not a very common
scenario.
Disable DirectFB for static builds.
Fixes:
http://autobuild.buildroot.org/results/3d3/3d3036d40ddad71d872d910aae7a24975706d2e9/http://autobuild.buildroot.org/results/d1c/d1c35a6003396942b584f2f2a5e8bf4ac2fbe370/http://autobuild.buildroot.org/results/d45/d4504871bd47930e8363032d380cdfcc5bb8aee7/
[...]
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>
Drop all patches, they're upstream.
And match that by dropping autoreconf as well.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
