When the .config contains invalid configuration *(e.g. two providers for
a same virtual package), it is not possible to run "make distclean"
because the .config file is sourced and packages interpreted in this
case.
Add distclean to the noconfig list, so that we can run it in all cases.
However, this meand that DL_DIR is no longer set, and thus the default
download location never removed. We fix that by always removing the
download location, so that if it is the one configured we still remove
it (no change) and if it is not the one configured, we remove an
non-existing location and leave the user's location intact (no change
either).
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>
Currently all cmake packages depend on host-cmake. Unfortunately
host-cmake takes a long time to configure and build: almost 7 minutes
on a dual-core i5 with SSD. The time does not change even with ccache
enabled.
Indeed, building host-cmake is avoidable if it is already installed on
the build host: CMake is supposed to be quite portable, and the only
patch in Buildroot for the CMake package seems to only affect
target-cmake.
Thus we automatically skip building host-cmake and use the one on the
system if:
- cmake is available on the system and
- it is recent enough.
First, we leverage the existing infrastructure in
support/dependencies/dependencies.mk to find out whether there's a
suitable cmake executable on the system. Its path can be passed in the
BR2_CMAKE environment variable, otherwise it defaults to "cmake". If
it is enabled, found and suitable then we set BR2_CMAKE_HOST_DEPENDENCY
to empty; otherwise we set BR2_CMAKE_HOST_DEPENDENCY to 'host-cmake' and
override BR2_CMAKE with "$(HOST_DIR)/usr/bin/cmake" to revert to using
our own cmake (the old behaviour).
Then in pkg-cmake.mk we replace the hard-coded dependency on host-cmake
to using the BR2_CMAKE_HOST_DEPENDENCY variable, and we use $(BR2_CMAKE)
instead of $(HOST_DIR)/usr/bin/cmake.
Unlike what we do for host-tar and host-xzcat, for host-cmake we do
not add host-cmake to DEPENDENCIES_HOST_PREREQ. If we did, host-cmake
would be a dependency for _any_ package when it's not installed on the
host, even when no cmake package is selected.
Cmake versions older than 3.0 are affected by the bug described and
fixed in Buildroot in ef2c1970e4 ("cmake: add patch to fix Qt mkspecs
detection"). The bug was fixed in upstream CMake in version 3.0 [0].
Amongst all the cmake packages currently in Buildroot, the currently
highest version mentioned in cmake_minimum_required() is 3.1 (grantlee
and opencv3).
Thus we use 3.1 as the lowest required cmake for now, until a package is
bumped, or a new package added, with a higher required version.
[0] https://cmake.org/gitweb?p=cmake.git;h=e8b8b37ef6fef094940d3384df5a1d421b9fa568
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Davide Viti <zinosat@tiscali.it>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
[yann.morin.1998@free.fr:
- simplify logic in check-host-cmake.mk;
- set and use BR2_CMAKE_HOST_DEPENDENCY, drop USE_SYSTEM_CMAKE;
- bump to cmake 3.1 for grantlee and opencv;
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This new package provides Xvisor, an open-source type-1 hypervisor,
which aims at providing a monolithic, light-weight, portable, and
flexible virtualization solution.
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
[Thomas:
- use MKIMAGE_ARCH instead of BR2_ARCH when calling mkimage
- use $(MKIMAGE)
- license is GPLv2+.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Kconfig clones, such as openconf used by xvisor [1], do not look for
.config at the root of the build directory, but in a subdirectory (e.g.
build/openconf).
This patch introduces a new Makefile variable named
$(2)_KCONFIG_DOTCONFIG, which contains the path to .config relative to
the source directory of the package. It defaults to .config and can be
overridden in the package Makefile.
It also creates the full directory hierarchy where the .config file is
stored, in case it does not exist (e.g. in xvisor).
This allows the use of the kconfig-package infrastructure with packages
relying on such clones.
[1] https://github.com/xvisor/xvisor/tree/master/tools/openconf
Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: use "install -D" instead of "mkdir + cp", as suggested by
Yann.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, calling foo-reconfigure for a kconfig-based package will not
re-trigger the configuration (kconfig-wise) step for the package.
This can be problematic when using an override-srcdir suring development
and the content of the veride-srcdir changes (e.g. on a rebase, a merge,
or during a bisect).
This is because the configuration (kconfig-wise) of the package is not
done in the _CONFIGURE_CMDS block, but as a separate action that is not
part of any step [0].
So, be sure to remove the stamp file .stamp_kconfig_fixup_done during
the foo-clean-for-reconfigure rule, so that the configuration is applied
again with the new source tree.
We use another rule, foo-clean-kconfig-for-reconfigure, because we do
not want to override the default foo-clean-for-reconfigure rule, and we
have no way to add conditional commands to it.
[0] The reasons it was not done are not entirely clear in my head, but
IIRC that was not working at the time we tried with Thomas DS.
Reported-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: 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>
The "log.{h,hxx}" header files are included from libupnpp.
As we are using the pkg-config file of libupnpp to get the header
include path, instead of the hardcoded `{prefix}/include/libupnpp`
these files are not found.
Upstream-status: https://github.com/medoc92/upmpdcli/issues/46
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building upmpdcli aborts because of an unsafe header inclusion of
`/usr/include/libupnpp`. Using `{prefix}` to get the header path is
wrong for cross-compilation.
Instead of hard-coding the flags for libupnpp use pkg-config to get the
correct ones.
Note that this patch adds the host-pkgconfig dependency unconditionally and
removes the necessity to pass the libupnpp manually to LIBS for a static
build.
Upstream-status: https://github.com/medoc92/upmpdcli/pull/49
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Starting with version 1.2 upmpdcli depends on libmicrohttpd and jsoncpp.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
upmpdcli now uses C++11 features, meaning the minimum usable GCC version
is 4.7.
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Apply a patch from upstream to install a pkg-config file for libupnpp.
Fetch from:
9f03bb0e7b
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
blkiomon.c assumes that clock_nanosleep() is always available. But it
is only available with NPTL. Since it unconditionally uses it, we add
dependency on NPTL.
Fixes:
http://autobuild.buildroot.net/results/c87/c87cd4a7b0bed938506bcf7e88d4cda60e28e6e5/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It is not directly obvious why we select pcre but not add it to the .mk
file, so add a comment to clarify.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
There's nothing holding it off for uClibc-based toolchains so enable it.
Signed-off-by: Gustavo Zacarias <gustavo.zacarias@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libcap-ng.so library is released under LGPLv2.1+ and programs testcap,
filecap, netcap and pscap are released under GPLv2+.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Programs are released under GPLv2+. README file says libraries
libaudit.* and libauparse.* are released under LGPL but there are two
files auparse/strsplit.c and lib/strsplit.c which are released under
GPLv2+ which makes both libraries GPL. Until we review situation with
upstream, we simply mention "unclear (libraries)".
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
[Thomas: add "unclear (libraries)" as suggested by Arnout.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit upstream 51925b7dd6d0("package/audit: Bump to version 2.6.5")
removed patch 0002 as part of version bump. But forgot to disable
autoreconf.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
login and hwclock can be built with audit support. This patch adds
optional dependency on audit package if it is already selected.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
fdisk and sfdisk tools can be built with readline support. This patch
adds optional dependency on readline if it is already selected.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
And copy firmware for BCM43430 and BCM43438, hence rpi3 wifi support at
last.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
There is no need to handle this return code, so just remove it.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This reverts commit 57e61a9153.
The patch doesn't apply, and makes the urg package fail in all
situations.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we use a mainline kernel for wandboard, we no longer
need to select BR2_LINUX_KERNEL_CUSTOM_GIT, so remove it.
This fixes the following warning:
make wandboard_defconfig
/configs/wandboard_defconfig:19:warning: override: BR2_LINUX_KERNEL_CUSTOM_VERSION changes choice state
#
# configuration written to /home/fabio/buildroot/.config
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
