Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
[yann.morin.1998@free.fr: fix missing double-quote at end of comment] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The way the compositor was selected in Config.in was counter-intuitive,
because the fbdev backend is selected by default even if a different one
is available.
Instead, select the fbdev backend only if no other one was selected by
the user.
Peter Seiderer [Mon, 14 Oct 2013 18:24:31 +0000 (20:24 +0200)]
support/kconfig: Fix typo in README.buildroot.
Fix typo in README.buildroot (s/config/kconfig/).
Signed-off-by: Peter Seiderer <ps.report@gmx.net> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Sat, 12 Oct 2013 10:15:08 +0000 (12:15 +0200)]
package: fix 'local' site method for host packages
Using the 'local' site method works just fine for target
packages. However, for host packages, when HOST_<pkg>_SITE is
automatically defined by the package infrastructure to be equal to
<pkg>_SITE, when defining the <pkg>_OVERRIDE_SRCDIR, the $($(2)_SITE)
is empty, due to a missing additional dollar sign.
This patch ensures that the <pkg>_OVERRIDE_SRCDIR gets the correct
value, regardless of whether the HOST_<pkg>_SITE variable has been
defined by the package itself, or inferred by the package
infrastructure using the <pkg>_SITE value.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Luca Ceresoli [Fri, 11 Oct 2013 20:37:43 +0000 (22:37 +0200)]
boost: Fix compilation of Boost.Variants move assignment
Fix compilation of Boost.Variants move assignment for situations when one of the variant template classes has nothrow copy constructor and throwing move constructor (refs #8772)
Fixes compilation error:
.../output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/boost/variant/variant.hpp: In member function 'void boost::variant<T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19>::move_assigner::internal_visit(RhsT&, int) [with RhsT = boost::shared_ptr<void>, T0_ = boost::shared_ptr<void>, T1 = boost::signals2::detail::foreign_void_shared_ptr, T2 = boost::detail::variant::void_, ..., T18 = boost::detail::variant::void_, T19 = boost::detail::variant::void_]':
...
.../output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/boost/variant/variant.hpp:2058:13: error: no matching function for call to 'boost::variant<boost::shared_ptr<void>, boost::signals2::detail::foreign_void_shared_ptr>::move_assigner::assign_impl(boost::shared_ptr<void>&, nothrow_copy, nothrow_move_constructor, boost::variant<boost::shared_ptr<void>, boost::signals2::detail::foreign_void_shared_ptr>::has_fallback_type_)'
Thomas Petazzoni [Sun, 13 Oct 2013 08:28:20 +0000 (10:28 +0200)]
toolchain-external: add a specific check to avoid Angstrom toolchains
The Angstrom toolchains available at
http://www.angstrom-distribution.org/toolchains/ are not usable as
external toolchains in Buildroot, because they are not pure toolchains
with just the C library, but instead complete SDKs with many
cross-compiled libraries (Gtk, Qt, glib, neon, sqlite, X.org, and many
more, approximately 200 MB of libraries).
Buildroot cannot use such toolchains, and while this is documented in
our manual, some users still try to do this. Today, one such user came
on the IRC channel, reporting a build problem, which we started
investigating, only to realize after a long time that he was using an
Angstrom toolchain.
To avoid this problem in the future, we explicitly check if the
toolchain is from Angstrom by looking at the vendor part of the tuple
exposed by the toolchain: as soon as it is
<something>-angstrom-<something-else>, we reject the toolchain with an
explanation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ruby: fix 'pcrel too far' build problem on SuperH architectures
The 'pcrel too far' problem detected in the autobuild on SuperH
architectures, seems to be caused by the -Os optimization flag. Using
standard optimization fixes the problem.
Investigated-by: Lionel Orry <lionel.orry@gmail.com> Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Sat, 12 Oct 2013 22:46:15 +0000 (00:46 +0200)]
package/rpi-userland: install all of our .pc files the same way
Install bcm_host the same way we install egl.pc and glesv2.pc, using
the cmake lists.
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>
The original titles did no longer correspond with the actual menu names.
Additionally, choose a name that better reflects the fact that this is a
list.
Signed-off-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>
The resulting weston works almost flawlessly, but requires a bit
of love:
- /boot/config.txt must include this line: dispmanx_offline=1
- at least 128MiB of RAM must be allocated to the GPU
- after 24-or-so terminal-clients are connected, the screen
turns black. Exiting a client restores the screen
It seems increasing/decreasing the amount of memory allocated to
the GPU makes the clients limit to wobble above/below 24 clients
at a time. YMMV, as they say...
Without dispmanx_offline=1, the limit is much below 24, at around 13.
But changing the amount of memory allocated to the GPU does not change
this limit in this case. YMMV, again.
Anyway, there are not many different clients available, besides the
terminal client, since all other clients are EGL-based, and there
is (yet) no EGL support (for weston!) on the RPi. So the tests were
made only with the terminal client.
The system is rather smooth, but spwaning too many clients in a
rapid-fire is sure to exhibit some lag. Resizing windows is a bit
jerky, but moving them along is fine.
Note: the config option has a depends on THREADS due to rpi-userland,
even though weston itself already inherits the same dependency from
wayland. But better be clean and safe.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Thu, 10 Oct 2013 21:05:24 +0000 (23:05 +0200)]
package/rpi-userland: add patch to remove faulty assert()
While porting wayland/weston to run on the RPi, I always tripped on
this assert.
Thinking there was an issue with weston, I poked the weston guys on
IRC about the issue. 'daniels' on irc.freenode.net/#wayland suggested
removing the assert altogether, as that's what they had pushed
upstream in their wayland pull-request:
https://github.com/raspberrypi/userland/pull/92
Turns out they forgot to include this in their pull-request, but that
they were using a patched rpi-userland without that assert.
And indeed, without that assert, weston runs on the RPi. :-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Thu, 10 Oct 2013 21:05:21 +0000 (23:05 +0200)]
package/weston: fix configure.ac to check for wayland-scanner
configure whines while checking for wayland-scanner.
wayland-scanner is used to generate the protocol parser C files from
the protocol definition XML files.
weston has a hard-dependency on wayland-scanner, so it can regenerate
its shell/mouse/keyboard/... "handlers".
Since we're using a tarball, those protocol files are already generated
and up-to-date, but the check is hard-coded and unconditional. If
wayland-scanner is missing, configure fails.
We could well patch away this check, but we'd have to carry and maintain
it probably for ever.
Better to fix it: add a patch from upstream weston to fix configure
whining.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Thu, 10 Oct 2013 21:05:20 +0000 (23:05 +0200)]
package/wayland: install wayland-scanner to $(HOST)
wayland-scanner is needed by weston.
[Peter: use $(INSTALL), fixup white space] 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>
Yann E. MORIN [Thu, 10 Oct 2013 21:10:33 +0000 (23:10 +0200)]
package/rpi-firmware: bump version
Fixes for de-interlacing of /unusual/ MPEG streams.
Yes, some people seem to enjoy generating MPEG streams in
which interlacing is not constant. That's apparently 100%
valid, but yet very unusual, and at the very least, weird.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fatih Aşıcı [Fri, 20 Sep 2013 05:43:15 +0000 (08:43 +0300)]
qt5: remove configure options from module packages
These packages do not have configure scripts.
Signed-off-by: Fatih Aşıcı <fatih.asici@gmail.com> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Tue, 8 Oct 2013 22:09:49 +0000 (00:09 +0200)]
package/weston: requires host-pkgconf
weston's configure.ac uses PKG_CHECK_MODULES,
so it needs to depend on host-pkgconf.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Yann E. MORIN [Tue, 8 Oct 2013 22:09:48 +0000 (00:09 +0200)]
package/weston: fix variable name
The weston package uses the $(WAYLAND_VERSION) variable instead of
$(WESTON_VERSION).
This went unnoticed for now, as we were using the same version for
wayland and weston. But that's not always the case, since we have,
for example: wayland-1.2.1 and weston-1.2.2, and no wayland-1.2.2.
Fix this by using the correct variable.
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>
Yann E. MORIN [Tue, 8 Oct 2013 22:09:47 +0000 (00:09 +0200)]
package/rpi-userland: rename patches
Rename patches to follow standard naming scheme.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: license is GPLv2] 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: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The configure script is out of sync causing deplibs linking issues so
recreate it. Fixes:
http://autobuild.buildroot.net/results/006/00673f04d0ce6cb0c5828e68f236a4eb8d7920db/
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-external: fix Linaro ARM toolchain support
This commit fixes bug #6452 (eglibc from Linaro 2013.07 not copied to
target correctly) by:
* Copying only the relevant library loader to the target on ARMhf
(i.e ld-linux-armhf.so and not ld.so*). This is needed since Linaro
toolchains provide two library loaders, one ARMv7 hf, and one ARMv4
soft-float.
* Making sure a $(TARGET_DIR)/lib/arm-linux-gnueabihf/ symbolic link
to $(TARGET_DIR)/lib/ exists, since the dynamic loader of Linaro
toolchains expects libraries to be found in
$(TARGET_DIR)/lib/arm-linux-gnueabihf/.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The copy_toolchain_lib_root function is responsible for copying a
given library (and its symbolic link) to the target filesystem. To do
so, it looks for the library in various locations, and then iterates
over the symbolic link all the way to the library, copying them as
needed to the target filesystem.
However, the latest Linaro toolchains bring an interesting use case:
the lib/ directory in the toolchain is organized as follows:
- ld-linux.so.3 -> arm-linux-gnueabi/ld-2.17...so
- ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.17...so
- arm-linux-gnueabi/
- all ARMv4T soft float libraries
- arm-linux-gnueabihf/
- all ARMv7 hard float libraries
In order to match what we do with all other toolchains, we want all
those libraries and symbolic links to be copied directly under
$(TARGET_DIR)/lib. This commit does that by adjusting the copy logic.
This is part of the fix for bug #6452 (eglibc from Linaro 2013.07 not
copied to target correctly).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-external: add support for musl C library
This commit adds support for external toolchains based on the musl C
library, as available from http://www.musl-libc.org.
Note that the pre-built musl toolchains available from
http://musl.codu.org/ are not working for the moment, since they lack
sysroot support. However, this problem has been reported to the
maintainer, who has already added sysroot support in his scripts at
https://bitbucket.org/GregorR/musl-cross, and therefore the next
version of the pre-built toolchains should work with Buildroot
out-of-the-box. In the mean time, the musl-cross script must be used
to build the toolchain.
[Peter: reword comment] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain: do not check largefile, wchar, IPv6 and locale for glibc toolchains
The check_glibc function contained checks to verify that the user had
properly enabled the largefile, IPv6, locale and wchar options, to
match how glibc is configured. This was useful when the support for
glibc external toolchains was introduced, but since then, we added the
BR2_TOOLCHAIN_USES_GLIBC symbol that automatically enables largefile,
IPv6, locale and wchar support when a glibc or eglibc external
toolchain is used. Therefore, many of the check_glibc checks are
useless now, so we can remove these.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit fixes various typos and mistakes in the comment at the top
of the helpers.mk file:
* usefull -> useful
* The optional stripping of libraries no longer exists, so there's no
reason to mention it.
* Indicate that the copy_toolchain_lib_root function is also used by
the glibc package, not only by the external toolchain logic.
* Separate more clearly the top comment introducing the entire file,
from the comment introducing the first function.
[Peter: reword top comment, add missing 'by'] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain: modify the wildcard logic for shared libraries copying
Until now, the copy_toolchain_lib_root function took as argument the
base name of a library (e.g: libm.so), and was assuming that the usual
scheme libm.so.<x> being a symbolic link to the real library was used.
However, with musl based toolchains, the C library is named libc.so
directly, with no symbolic link at all. Therefore, this commit changes
the copy_toolchain_lib_root to move the responsibility of using a
wildcard or not after the library name the caller's responsibility.
So, all the existing LIB_EXTERNAL_LIBS values are modified to have a
.* at the end, so that the behavior is effectively unchanged.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-external: conditionalize the installation of libraries
The external toolchain code makes the assumption that all C libraries
have a ld*.so, libc.so, libcrypt.so, libdl.so, libgcc_s.so, libm.so,
libnsl.so, libresolv.so, libutil.so, and when thread support is
enabled, libpthread.so, etc.
However, this is not the case with the musl C library, which
integrates all the functionalities in a single libc.so file. In
preparation of the support of the musl library, we make the current
value of LIB_EXTERNAL_LIBS conditional to glibc or uClibc.
The addition of additional libraries through
BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS is kept outside the condition, at
the end.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The dependencies-source, dependencies-clean and dependencies-dirclean
targets are not needed, as long as 'dependencies' is not used in the
<pkg>_DEPENDENCIES of a package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-external: convert to the package infrastructure
This commit converts the 'toolchain-external' logic to the package
infrastructure.
The TOOLCHAIN_EXTERNAL_DIR variable (which points to where the
toolchain is located) is renamed to TOOLCHAIN_EXTERNAL_INSTALL_DIR,
because the former conflicts with the package infrastructure (which
defines the <pkg>_DIR variable for each package as pointing to its
build directory).
The new _EXTRA_DOWNLOADS mechanism is used for Blackfin toolchains.
The extract, configuration and installation steps are converted inside
the <pkg>_EXTRACT_CMDS, <pkg>_CONFIGURE_CMDS and
<pkg>_INSTALL_STAGING_CMDS.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
toolchain-buildroot: convert to the package infrastructure
This commit converts the toolchain-buildroot logic to the package
infrastructure. The package is fairly simple as it only defines
BUILDROOT_LIBC, and depends on host-gcc-final to get the overall
internal toolchain build logic started.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit introduces a virtual package called 'toolchain', located
in 'toolchain/toolchain', which simply depends on
'toolchain-buildroot' or 'toolchain-external' depending on the
selected toolchain backend.
For now, toolchain-buildroot and toolchain-external are still manual
make targets, but the following patches convert those backends to use
the package infrastructure as well.
In addition to this:
* The main Makefile is modified to always make BASE_TARGETS point to
this new toolchain virtual package.
* The main Makefile is changed to include all the toolchain/*/*.mk
files: the toolchain virtual package, and the toolchain-buildroot
and toolchain-external directories.
* The dependency of the toolchain on prepare dirs and dependencies is
moved to the toolchain virtual package. It is moved as a
prerequisite of the "toolchain-source" rule to ensure that all
directories are prepared before we even start extracting the
toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Converting the external toolchain logic into a package raises a very
special use case that wasn't handled by the package infrastructure:
the Blackfin toolchain is delivered as two tarballs instead of
one. Unfortunately <pkg>_SOURCE only allows to pass one tarball name.
However, we really want both tarballs to be known by the package
infrastructure, so that the normal 'source' and 'external-deps'
mechanism work fine.
In order to achieve this, we add a <pkg>_EXTRA_DOWNLOADS variable,
which allows a package to list other stuff it would like to see
downloaded, but that are otherwise not used by the package
infrastructure itself: it is up to the package to do it by itself.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
glibc: fix glibc build by creating an empty gnu/stubs.h
The stubs.h header is not installed by install-headers, but is needed
for the gcc build. An empty stubs.h will work, as explained in
http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick is
used by Crosstool-NG.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Until now, only the eglibc build was pulling host-gawk as a
dependency, but after more testing, it turns out that the glibc build
also requires host-gawk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
projects / coffee / buildroot.git / log