Build with uclibc and locale support failes with the following error
message:
regc_pg_locale.c: In function ‘pg_wc_isdigit’:
regc_pg_locale.c:312:6: error: dereferencing pointer to incomplete type
isdigit_l((unsigned char) c, pg_regex_locale));
This can be fixed by overwriting the HAVE_LOCALE_T detection (thanks
to Alex Potapenko <opotapenko@gmail.com> for the hint [1]).
[1] http://lists.busybox.net/pipermail/buildroot/2015-March/121088.html
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Useful for packages shipped with a testsuite which makes use of ctest
Since ctest is just a tool provided by the cmake sources, this change
introduces a hidden BR2_PACKAGE_CMAKE symbol which is automatically
selected by the BR2_PACKAGE_CMAKE_CTEST one.
This is like this mostly for consistency (cmake is the actual package,
not ctest).
CMake is a particular package:
* CMake can be built using the generic infrastructure or the cmake one.
Since Buildroot has no requirement regarding the host system cmake
program presence, it uses the generic infrastructure to build the
host-cmake package, then the (target-)cmake package can be built
using the cmake infrastructure;
* CMake bundles its dependencies within its sources. This is the reason
why the host-cmake package only has host-pkgconf as (runtime)
dependency, whereas the (target-)cmake package has a lot of
dependencies, using only the system-wide libraries instead of
rebuilding and staitcally linking with the ones bundles into the CMake
sources.
[Thomas:
- add missing C++ dependency.
- add missing multiple 'select' in Config.in
- add missing wchar dependency, inherited from selecting libarchive.]
Signed-off-by: Davide Viti <zinosat@tiscali.it>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that libnl pkg-config file is correct, there is no need to have
special handling for static linking in the iw package: it already uses
pkg-config to get the necessary flags to link with libnl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Instead of hardcoding the dependencies of libnl, use pkg-config to
discover them.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Having a properly defined Libs.private field allows to make sure
static linking against libnl-3.0 works fine, at least as long as
pkg-config is used.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Now that Jörg's patch has been merged upstream, let's use the
backported version, in a git format.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yannick Kiekens <yannickkiekens@gmail.com>
[Thomas: tested on ARM uClibc, and AArch64 glibc, the latter being the
case that used to fail building, and was the reason why boost log had
been disabled.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When an external toolchain is used on ARC, BR2_BINUTILS_VERSION is
undefined, so we use binutils 2.22, which doesn't support ARC and
anyway isn't available from the ARC download location.
So, let's defined a default ARC binutils version in binutils.mk.
Fixes:
http://autobuild.buildroot.org/results/52a/52abadacd7aab2d5c11d094937f28198bf220662/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The computation of TOOLCHAIN_EXTERNAL_BIN has a special case for
Blackfin, where it's set to
$(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/$(TOOLCHAIN_EXTERNAL_PREFIX)/bin
instead of $(TOOLCHAIN_EXTERNAL_INSTALL_DIR)/bin for other
architectures.
However, this is actually only true for Analog Devices pre-built
toolchains. Other Blackfin external toolchains (such as ones built by
Buildroot) do not have this special organization.
Therefore, in order to make those non-ADI Blackfin toolchains work, we
need to change the condition from BR2_bfin to testing specifically for
the ADI toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libdri2 is a library for the DRI2 extension to the X Window System. This
is the split out dri2 client side code from mesa, libva, libvdpau, etc..
It can be used by applications or user-space drivers to provide
accelerated graphics.
Signed-off-by: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
/home/buildroot/instance-0/output/build/host-softether-16b713b98da8dba29f0f845d5a8c36d6f7c34824/src/Mayaqua/Unix.c:2066:
undefined reference to `clock_gettime'
[Thomas: remove commit 7663664113, which
was a different fix for the same problem.]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
zmqpp recommand at least a c++ compiler g++ >= 4.7
[1] for c++11 support and won't be backward compatible
whith older compliler for the next release (4.x)
due to harcoded -std=c++11 flag [2]
Blackfin ADI toolchains use a g++ 4.3 which use an
experimental c++11 support (c++0x) has not enough c++11
support to build zmqpp.
Fixes:
http://autobuild.buildroot.net/results/4c3/4c34ce881e3eab47994cc893898cbc9129ce67b5/
And many more.
[1] https://github.com/zeromq/zmqpp
[2] f078fe9a5a
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The git hash 36413487f05b165dfc82ad307a5a1c36a795e607 no
longer refers to any commit id, even in the previous git tree.
By reading the Makefile and CHANGELOG.md the last know
release is 3.2.0.
Switch to the official git tree and use the 3.2.0 release tag.
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Backport and rebase a patch from upstream:
313714f8b7
Also, remove the fix in czmq.mk for static build.
Fixes:
http://autobuild.buildroot.net/results/ec4/ec414b52f9cdd8d7d365283e21479519e63c7d97/
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
kconfig string option values should use double quotes when defined, so
this commit fixes package/uclibc/Config.in in that respect.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Changes are here http://uclibc-ng.org/pipermail/devel/2015-March/000114.html
Buildroot related are SPARC and XTENSA non-threading builds
and static linking fixes for pthread apps like cdrkit.
Add a hotfix for MIPS compile with older GCC.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For the moment, we probably don't want to have several versions of
uClibc-ng supported at the same time. In preparation to the bump of
uClibc-ng to 1.0.1, this commit gets rid of the version number from
the uclibc-ng config option so that we don't have to rename this
option over and over again each time a new uClibc-ng release is
made. This would be annoying in terms of Config.in.legacy handling.
Since the option BR2_UCLIBC_NG_VERSION_1_0_0 has never been part of
any Buildroot release, we don't have to add anything to
Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There is no need to warn the user about selecting an inappropriate
thread implementation, since we make sure only supported combinations
can be selected.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uClibc-ng does not support linuxthreads or linuxthreads.old on
architectures that have NPTL support. This creates another complicated
dependency: dependeing on the uClibc version being used, not the same
thread implementations are available.
In order to handle this situation, this patch introduces three hidden
booleans:
- BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS
- BR2_UCLIBC_VERSION_SUPPORTS_LINUXTHREADS_OLD
- BR2_UCLIBC_VERSION_SUPPORTS_NPTL
They are selected by the different uClibc versions, depending on which
thread implementation they support on the different architectures.
Then, the choice of the thread implementation can rely on those
booleans to know if a given thread implementation is available in the
current architecture / uClibc version selection.
This makes sure that unusable thread implementation do not get
selected, therefore fixing build issues such as:
http://autobuild.buildroot.org/results/89e/89e423bee040cbce3e82cd89f1191efaac490c0d/
The support table is as follows (only taking into account
architectures that allow the selection of
BR2_TOOLCHAIN_BUILDROOT_UCLIBC, other architectures are not
considered) :
----uclibc---- uclibc-xtensa- --uclibc-arc-- --uclibc-ng---
LT LT.old NPTL LT LT.old NPTL LT LT.old NPTL LT LT.old NPTL
arc(le|eb) y y n n n n (1)
arm(eb) y y y n y y (2)
bfin n y n y y n
i386 y y y n n y (3)
m68k y y y y y n
mips(64)(el) y y y n n y
powerpc y y y n n y
sh y y y n n y
sparc y y y n n y
xtensa n y n n n y
x86_64 y y y n n y
(1) : uclibc-ng only has NPTL support for ARC but it requires a more
recent compiler version that hasn't been officially released
by Synopsys.
(2) : the general idea of uclibc-ng is to only support NPTL on
architectures where it is available. However, in order to
support ARM noMMU platforms, LT.old support has been kept on
ARM.
(3) : except i386 itself, which doesn't have what's needed for NPTL
support. i386 is simply not supported by uclibc-ng basically.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
iotop does for I/O usage what top does for CPU usage.
Signed-off-by: Christophe Vu-Brugier <cvubrugier@fastmail.fm>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It was disabled in february 2013 by commit
e5434583ba
because did not build correctly with ucLibc at the time.
It now builds correctly with both uClibc v0.9.33 and uClibc-ng.
Signed-off-by: Noé Rubinstein <nrubinstein@aldebaran.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
