The plugin registry can take a while to be generated when GStreamer is
initialized. Turning it off can speed up up GStreamer application launch
times. Default behaviour is unchanged.
Signed-off-by: Tim Sheridan <tim.sheridan@imgtec.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
On ARM, Linaro external toolchains are only visible if the user
selects Cortex-A8 or Cortex-A9. Therefore, we add a comment that tells
the user that the Linaro toolchains are only available under those
conditions.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In order to solve
http://autobuild.buildroot.org/results/34f6843137efda20626af72714c110280ec577d7/build-end.log,
this patch makes the D-Bus package as well as all the packages that
select the D-Bus package 'depends on BR2_USE_MMU'.
In addition, for the specific case of gvfs, the missing
BR2_TOOLCHAIN_HAS_THREADS dependency is added (threads are required by
D-Bus, so they are also required by gvfs which selects D-Bus).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
uClibc pretends to implement <fenv.h> as it installs the header, but
in practice, it only implements the functions for i386. This makes gsl
unhappy as it detects fenv.h, but then cannot use the fenv functions.
Fixes:
http://autobuild.buildroot.org/results/732cc07faeca2a9098dc5106e8f654eb1323451a/build-end.log
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The 1.2 we were using doesn't build on ARM Thumb platforms:
http://autobuild.buildroot.org/results/94ef6be7dcb31021462e7313724217627d4b29df/build-end.log
Moreover, the 7.2 version is the one used by Debian/Ubuntu, and it has
been tested to build fine with the two packages that depend on
libatomic_ops: libdrm and pulseaudio.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
mesa3d now generates some C files at build time (related to the OpenGL
API) from XML files. This generation process is done using Python
scripts that require the libxml2 Python module.
Patch based on the initial work of Will Wagner (Thanks Will).
Signed-off-by: Vellemans Noel <noel.vellemans@visionbms.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Patch based on the initial work of Will Wagner (Thanks Will).
libxml2 host library with python support is required to build mesa3d (7.10.1)
Signed-off-by: Vellemans Noel <noel.vellemans@visionbms.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit 3c90f75496 made Python use a
special ./configure command in order to avoid --enable-shared
--disable-static being passed, because it was causing issues when
building certain modules for a 64 bits system.
However, not having a shared libpython2.7 library for the host
prevents the libxml2 Python binding to get built.
So instead, we use the default configure command, but we add
--enable-static which is needed for Python to build correctly.
Note that we tested the build of Python on a 64 bits host as well as
the build of Python for a 64 bits target, and both went fine, with all
modules built properly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
(Possibly) fixes#5354
The lua shared library patch was creating the shared library with
-nostdlib -lgcc for some unknown reason, which most likely is
the reason for the link issue reported in #5354.
Fix it by dropping these arguments, so gcc gets to figure out itself
what dependencies are needed.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Using severals post build scripts is usefull to share
script between severals boards/projects.
[Peter: fix trailing spaces in Config.in]
Signed-off-by: Philippe Reynes <philippe.reynes@sagemcom.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A very common mistake done by our users is that they use
output/target/ directory as their root filesystem. Even though this is
loudly documented in our Buildroot manual, people don't read
documentation, so it is not sufficient.
This patch adds a text file named
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM which explains why
output/target isn't appropriate to use as the root filesystem. The
process is:
* At the beginning of the build, right after the skeleton has been
copied, support/misc/target-dir-warning.txt is copied to
output/target/THIS_IS_NOT_YOUR_ROOT_FILESYSTEM
* In the filesystem images creation code, this file is removed before
launching fakeroot, and restored right after that, so that this
file is not present in the generated root filesystem images.
Note that the file has not been added to the default skeleton for two
reasons:
* It would have annoying to have in our source tree a file named in
capital letters inside system/skeleton/
* The proposed way works even if the user uses a custom skeleton.
[Peter: fixed typo]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Juha Lumme <juha.lumme@gmail.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
automake, autoconf, libtool and make on the target are basically
useless if we don't support building a toolchain on the target. Of
course, the host variant of automake, autoconf and libtool will remain
available.
[Peter: fixup to apply after perl change]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
As discussed during the ELCE 2012 Buildroot Developers Meeting, we no
longer want to support the possibility of building a toolchain for the
target. None of the core developers have any use for this, it has been
known to be broken or cause problems for a long time without anyone
providing fixes for it.
In addition to this, Buildroot is inherently a cross-compilation tool,
so the usage of a native toolchain on the target is not really
useful. Many newcomers are tempted to use this possibility even though
it is clearly not the intended usage of Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
