Defaulting to UTC (which is what uClibc will default to when /etc/TZ is
missing) seems more sensible than US Mountain Time Zone in the default
rootfs skeleton.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Problem was found when compiling libplayer with GStreamer support
on x86_64 with a Sourcery toolchain.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Implementation of an interface connecting TUIO messages and QT events
https://github.com/x29a/qTUIO
Signed-off-by: Stephan Hoffmann <sho@relinux.de>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
build-tested with a minimal internal toolchain for ARM.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
[Peter: drop uneeded configure args, full install to target]
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
This fixes the "Unknown parameter for tags/attrs" build error.
Backported from commit 88e08c43d0200a4b06a298b7d2541965eebc0afe
[PATCH] 2011-04-17 Thierry Reding
<thierry.reding@avionic-design.de>
Reviewed by Adam Barth.
Fix build with GCC 4.6.
* dom/make_names.pl: Execute preprocessor without the -P option. The
preprocessor in GCC 4.6 eats empty lines, effectively breaking the
parsing performed by this script. Dropping the -P option when invoking
the preprocessor keeps the empty lines but as a side-effect also adds
additional linemarkers.
From the cpp manpage:
-P Inhibit generation of linemarkers in the output from the
preprocessor. This might be useful when running the preprocessor
on something that is not C code, and will be sent to a program
which might be confused by the linemarkers.
The linemarkers are not problematic, however, because the script
properly handles them by ignoring all lines starting with a #.
Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Tested-by: Samuel Martin <s.martin49@gmail.com>
Acked-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
ld-linux*.so may not be present in lib/ directory, it could be
in lib32 and/or lib64 only. But check_glibc reports
"Incorrect selection of the C library" in this case, which is
not true.
Fixed by extending the search to SYSROOT/*/*.
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 11017f081f, the Crosstool-ng
backend generates toolchains that have a prefix inconsistent with what
Buildroot expects. Buildroot expects a "buildroot" vendor name, while
Crosstool-NG builds toolchain with the "unknown" vendor name.
This is causing build failure such as:
http://autobuild.buildroot.org/results/15b2c0e50a81b86dd13af684c9254df2bc0df8de/build-end.log
Fix this by changing the vendor part of the tuple used by Crosstool-NG
to "buildroot".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Fixes http://autobuild.buildroot.net/results/45a0856bafa9f2f7e86e2c063528c2b5b04c08d6
gnupg's configure script defaults to prepending an underscore ('_') to
the assembly level functions, which isn't correct for Linux and causes
linker errors for the archs where it has asm optimizations.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Host-only package that don't define their <PKG>_SOURCE variable would
default to host-<pkg>-<version>.tar.gz. It's more logical to remove
the host- prefix in this case.
This problem is most apparent with host-only packages downloaded from
version control, because they never define <PKG>_SOURCE.
Reported by Thomas Petazzoni and initial analysis by Luca Ceresoli.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The decode-tm6000 utility cannot build without the libv4l2util. If
this library is not available, the build breaks with:
decode_tm6000.o: In function `read_stream':
decode_tm6000.c:(.text+0x220): undefined reference to `v4l2_rcvbuf'
decode_tm6000.o: In function `main':
decode_tm6000.c:(.text+0x37c): undefined reference to `v4l2_open'
decode_tm6000.c:(.text+0x3cc): undefined reference to `v4l2_gettryset_fmt_cap'
decode_tm6000.c:(.text+0x424): undefined reference to `v4l2_getset_freq'
decode_tm6000.c:(.text+0x47c): undefined reference to `v4l2_mmap_bufs'
decode_tm6000.c:(.text+0x4a0): undefined reference to `v4l2_start_streaming'
See
http://autobuild.buildroot.org/results/207ed74d5e816309ef0dc82ecc8112b51788fdf6/build-end.log
We fix this by adding util/libv4l2util to the list of directories to
build when decode-tm6000 is enabled. The only other user of
libv4l2util is another utility called qv4l2, for which Buildroot has
no Config.in option, so we only handle the case of decode-tm6000 at
the moment.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
In libv4l.mk, if there are multiple elements in $(LIBV4L_DIRS_y), they
are built in order, one after the other. However, our loop construct
doesn't take into account the fact that we should error out if one of
the steps failed.
A good illustration is having BR2_PACKAGE_LIBV4L_DECODE_TM6000 and
BR2_PACKAGE_LIBV4L_V4L2_CTL enabled. The build of decode-tm6000 will
fail, but the build will happily continue without stopping in libv4l.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Even though the MMX instructions are available on x86_64 processors,
the MMX code in sdl_gfx is written in IA32-specific assembly code, and
therefore does not build on x86_64. It generates the following build
issues:
SDL_imageFilter.c: Assembler messages:
SDL_imageFilter.c:34: Error: `pusha' is not supported in 64-bit mode
SDL_imageFilter.c:38: Error: `popa' is not supported in 64-bit mode
SDL_imageFilter.c:77: Error: `pusha' is not supported in 64-bit mode
SDL_imageFilter.c:93: Error: `popa' is not supported in 64-bit mode
[...]
We fix this by only enabling MMX support in this package when the
processor supports MMX *and* it is a IA32 compatible processor.
Fixes
http://autobuild.buildroot.org/results/b9efc611f5da487079b6be37bb7a41a3198d63b9/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Cairo tracing and trace interpreter are most likely not that
useful, so disable them. They also require zlib, which isn't a
dependency of Cairo at the moment. This fixes the following build
failure:
http://autobuild.buildroot.org/results/a91e4e337fd9deb0f9fad433350feb27b2aee556/build-end.log
In the future, if people are interested by the trace and trace
interpreter, we can add a new Config.in knob for them.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
