Markos Chandras [Thu, 17 Oct 2013 08:33:25 +0000 (09:33 +0100)]
dropwatch: Remove -Werror from CFLAGS
-Werror shouldn't be used in released code since it can
cause random build failures on moderate warnings. It also
depends on the used toolchain since different toolchains may
or may not print the same warnings.
Fixes the following build problem on MIPS64/n64:
main.c: In function handle_dm_alert_msg:
main.c:336:5: error: format %llx expects argument of
type long long unsigned int, but argument 4 has
type __u64 [-Werror=format=]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Ryan Barnett [Wed, 9 Oct 2013 20:46:15 +0000 (15:46 -0500)]
manual: update review process and patchwork
Adding more documentaiton based on discussion from the mailing list
in regards the buildroot review process and how patchworks can be
used to pull in patches for testing purposes.
Mailing list discussion:
http://lists.busybox.net/pipermail/buildroot/2013-September/078170.html
Signed-off-by: Ryan Barnett <rjbarnet@rockwellcollins.com> Acked-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Gustavo Zacarias [Mon, 14 Oct 2013 14:15:11 +0000 (11:15 -0300)]
boost: fix build failures after version bump
Fix build failures that happened after the version bump such as:
http://autobuild.buildroot.net/results/570/570b091702763b29843d9207bc14dea67085fea0/
http://autobuild.buildroot.net/results/c26/c26498f1a4e6bcbc3a2dfce6a51fa7d21b72f21f/
and other failures by disabling the new (1.54+) coroutine and log
libraries which weren't handled and hence enabled by default.
These also made the target size bigger and build times longer
unnecessarily.
When/if they are needed for some future user this can be revisited and
their proper conditions for enablement assesed.
manual: add section about depending on target and toolchain options
Currently, the comments in Config.in files when depending on toolchain
options are not at all lined up. This patch adds a section to the
documentation that explains which format is to be used.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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>
projects / coffee / buildroot.git / log