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>
The ELDK now relies on Yocto, so it no longer has the funky
non-standard way of doing multilib. Also, we didn't mention that Yocto
toolchains/SDK are not suitable for usage with Buildroot. Therefore,
this commit rewords this part of the documentation to explain that
Yocto/OpenEmbedded SDKs cannot be used as external toolchains in
Buildroot, and why.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
Replace ADI by Analog Devices, which is clearer for most people, and
remove the Xilinx external toolchains since we have deprecated them.
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>
Now that we have eglibc and glibc support in the internal backend, and
no longer marked as experimental, a little bit of rewording is
needed. It is no longer necessary to indicate that uClibc was
historically supported as the only C library, and that the glibc
support is experimental. We also update the rest of the description to
be less uClibc specific.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
[Peter: adjust wording as suggested by Yann]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
There is no need to tell people that they should remove stamp files: they
should use the make <pkg>-reconfigure and make <pkg>-rebuild make targets
instead. We still keep an explanation about stamp files, just to give the
user an insight on how Buildroot works internally.
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>
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>
The conditional (suggested by me) introduced in 108952 (rt-tests: disable
for uclibc mips) isn't actually valid kconfig syntax, causing menuconfig to
error out.
Rewrite it to use proper syntax.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
rt-tests is not supported by a uclibc toolchain that does not implement
_pid in struct sigevent. Currently this is all MIPS architectures
in uclibc.
Fixes:
http://autobuild.buildroot.net/results/074/074265602bec4aba6c82d1aee389045e8ad33d4b
Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
For some architectures (eg. Arc, Cris, Hexagon, ia64, Parisc, Score and
Xtensa), the Linux buildsystem tries to call the cross-compiler when
installing the headers.
This is a spurious call, since a cross-compiler is not needed at all to
install the headers.
As some users have reported the issue, just add a comment in linux-headers.mk
directing the user to ignore those errors.
Reported-by: Noam Camus <noamc@ezchip.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To allow proper nesting of suboptions of a package, the suboptions should
come directly after the main option, and cannot be interleaved with a
comment.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
alsa-utils uses fork which is not available on targets without MMU support.
It seems to be possible to replace fork with vfork in alsa-utils, but we do
not like to carry such patches in buildroot without them being accepted
upstream.
Fixes
http://autobuild.buildroot.org/results/9f8/9f8e572c9f1c677155cc7d1828371bcf572ff878
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The AM_PATH_ALSA macro in utils/alsa.m4 unconditionally uses -ldl. This
breaks compilation of alsa-utils (and probably other packages using this
macro) for targets that do not support dynamic loading, such as for
Blackfin FLAT binaries.
This patch updates the macro to check if dlopen is available, and use that
result to conditionally add -ldl to the list of libraries.
Fixes
http://autobuild.buildroot.org/results/de2/de286880973be956f6c504aa9a758171d6f49674/build-end.log
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The FLAT GNU toolchain doesn't include the dlfcn.h header file.
Provide the necessary declarations (RTLD_*) to make alsa-lib happy.
Fixes
http://autobuild.buildroot.org/results/706/7069e1f43cbed745d65f7dd9904a3fff034530ac/build-end.log
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
[Thomas: change sequence number from 003 to 0003, update patch and commit
message ]
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit a9baea4345 ('pixman: add patch
to fix Microblaze build failure'), a patch is added to the pixman
package to avoid using the FE_DIVBYZERO definition when it is not
available. However, it was using the have_fe_divbyzero variable to
define or not HAVE_FEDIVBYZERO, while the AC_CHECK_DECL autoconf macro
sets the ac_cv_have_decl_FE_DIVBYZERO variable.
The end result was that the FE_DIVBYZERO macro was considered as never
being available. This commit fixes that by using the appropriate
variable.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages (actually, just oprofile) need to link against libiberty.
This option just installs libiberty.a so it has no effect on the target,
therefore it's not needed to add a config option for it.
Before binutils-2.24, there was a bug in libiberty/Makefile.in that
caused libiberty to be installed regardless of the
--enable-install-libiberty option. This problem wasn't noticed before
because binutils-2.24 is not selected on any of the autobuilders: the
version can only be selected if an internal toolchain is used, and it
defaults to 2.21.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The Microblaze build of pixman was failing due to FE_DIVBYZERO not
being implemented. It turns out that the usage of it, like fenv.h and
feenableexcept() is optional. So the patch simply adds a configure
check and disables the appropriate code (which is only use in the
tests anyway).
This commit also renames the existing patch to follow the patch naming
convention, and get a reliable ordering when applying patches.
Fixes:
http://autobuild.buildroot.org/results/806/8064092cdbac85fbf4322429d29d5d11dc51860f/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.
This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.
This hidden option is:
* Automatically enabled when glibc/eglibc or musl toolchains are
used, either internal or external.
* Automatically enabled when an internal uClibc toolchain with NPTL
support is configured. It is left disabled otherwise for internal
uClibc toolchains.
* Configured according to a visible Config.in option for custom
external uClibc toolchains.
[Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libcgi always builds both the shared and static library, which doesn't
work on architecture that don't support shared library at all, such as
Blackfin with the FLAT format. libcgi uses autoconf, but not automake,
and the Makefile is not of the highest possible quality, so this
commit fixes the problem by introducing a "STATIC" variable that can
be set from the environment. When set to a non-empty value, the
Makefile assumes it should only build the static version of the
library.
Note that this package is in desperate need of some care: there is one
single patch that mixes several changes together, it doesn't have a
description or a Signed-off-by line, and there is now a github project
for libcgi at https://github.com/rafaelsteil/libcgi/ that has the same
fixes.
However, for the purpose of the master branch, we're doing the most
minimal fix possible, by just adding this STATIC variable.
Fixes:
http://autobuild.buildroot.net/results/625/625105bcaf26345f422b225787fc19611b65cd57/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable when using a uclibc version before 0.9.33 since dn_comp
function support was added in this version. Also disabling on AVR32
since any AVR32 toolchain will be based on a uclibc version older
than 0.9.33 (for using an external AVR32 toolchain).
[Peter: use dn_comp instead of __dn_comp]
Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since quite a while, we have deprecated, and then removed the support
to build a compiler on the target. Therefore, having a distcc package
for the package is quite useless, and this patch consequently marks it
as deprecated so it can be removed in a future version of Buildroot.
Fixes:
http://autobuild.buildroot.net/results/16b/16be2138c8e5ba785fa2ad55b478dcd1b6fb5123/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Using a relative path for O=... has limitations, since it is interpreted
relative to the Buildroot tree, and thus may lead to unexpected results.
For example, running this:
make -C buildroot O=my-O
will not create my-O in the current working directory, but as a
sub-directory of the Buildroot tree, here in buildroot/my-O
Explain this in the manual (as is similarly done for BR2_EXTERNAL).
Also add a note that $(O) will be created if missing.
Also change O=.. and -C .. to O=<...> and -C <...> to make it explicit
this is an ellipse, not a relative path.
Reported-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Although it is possible to use relative paths, there are a few pitfalls
when doing so.
To avoid confusion for a (newcoming) user, use absolute paths in the
manual (as is done in examples for $(O)), since it is guaranteed to be
working without corner cases.
[Peter: s/relatively/relative/ as suggested by Thomas]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Using a relative path for BR2_EXTERNAL, and using an external defconfig,
such as in (from a Buildroot top-dir):
make O=.. BR2_EXTERNAL=.. foo_defconfig
is broken. It is unclear why the %_defconfig rule recurses in that case.
This patch internaly makes BR2_EXTERNAL canonical (ie. makes it an absolute
path), and checks the directory exists.
[Peter: s/relatively/relative/ as suggested by Thomas]
Reported-by: Jérémy Rosen <jeremy.rosen@openwide.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
mpg123 needs MMU because the application that is built with this
package uses fork. Currently it is difficult to only build the
libraries for mpg123 so disabling the package all together when there
is no MMU support.
Note: mpg123 is an optional dependency of mpd but mpd already requires
BR2_USE_MMU so there is no need to add this as a dependency.
Fixes:
http://autobuild.buildroot.net/results/5b0/5b053af566dd122ae7e58893e77d5d5f3070fb9e
Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 87492d244a ("aiccu: disable
for uClibc 0.9.31/0.9.32"), we made sure it was not possible to select
aiccu with uClibc 0.9.31 and 0.9.32, because they lack dn_skipname().
However, we still have the problem that external AVR32 toolchains can
select aiccu, which causes build failures. Therefore, we also disallow
aiccu on AVR32 altogether. We keep the 0.9.31/0.9.32 exclusions,
because if they are used on other architectures, it would also fail
due to the lack of dn_skipname().
Fixes:
http://autobuild.buildroot.org/results/a24/a2490d434152625d9208615d83f4c5d6daea79d0/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The libeina library uses the madvise() system call, that isn't
available on non-MMU systems. Also, several other components of EFL
use fork(). Therefore, the easiest solution is to simply disallow the
EFL as a whole on non-MMU systems.
Fixes:
http://autobuild.buildroot.org/results/ad9/ad90baa5e07569308a7e2b2510b67c5b2a563b44//
Thanks to Ryan Barnett for helping in the investigation!
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Evas has an optional mechanism to do asynchronous preloading of
images. This mechanism is optional, and in commit
b6d92bf415 ("libevas: async image
preload support needs threads support in toolchain"), Peter made sure
to disable the asychronous preloading when no thread support was
available.
Unfortunately, it seems like disabling the asynchronous loading is
rarely used, and it in facts fails to build: a member of structure is
not present when asynchronous preloading is disabled, but the code
continues to use it.
Since the fix is not obvious, and all this mechanism seems to have
changed completely in EFL 1.8.x, and we probably don't care much about
EFL without threads, this commit adds a dependency of libevas on
thread support. Consequently, it also reverts commit
b6d92bf415 which is no longer necessary.
Of course, this commit propagates this additional dependency to the
reverse dependencies of libevas.
Fixes:
http://autobuild.buildroot.org/results/6de/6de90018a9eeb9c495d15046a8b3270eb95a5550//http://autobuild.buildroot.org/results/693/693df99db4ab357b48d427be3a72f6d64dd53065//
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
To be sure that host-autoconf dependency is already built move the
call to autogen.sh from SDL_POST_PATCH_HOOKS to SDL_PRE_CONFIGURE_HOOKS.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The cross-compilation test is based on the ability to run
a test program on the host, which is wrong.
If it runs, then the configure script concludes
that we're doing native compilation,
if it doesn't run, we're doing cross-compilation.
The configure script needs to be regenerated to fix the
cross-compilation test.
Fixes
http://autobuild.buildroot.net/results/969/969a49ae97a50634ea846a82b9c360e4fb020ace/build-end.log
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
