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
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.
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.
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 <[email protected]> Reported-by: http://stackoverflow.com/questions/19311747/buildroot-cant-use-local-site-method-for-custom-host-packages Signed-off-by: Peter Korsgaard <[email protected]>
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.
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.
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.
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.
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. :-)
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.
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.
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.
The configure script is out of sync causing deplibs linking issues so
recreate it. Fixes:
http://autobuild.buildroot.net/results/006/00673f04d0ce6cb0c5828e68f236a4eb8d7920db/
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/.
projects / buildroot-mgba.git / log