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>
The mesa3d now requires the makedepend host utility, otherwise, it
fails with:
configure: error: makedepend is required to build Mesa
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Noel Vellemans <Noel.Vellemans@visionBMS.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The largefile patch is no longer necessary, it has been merged
upstream. However, in order to make the build work properly with
Thumb2 toolchains (such as Linaro toolchains), an additional fix is
needed. This fix is already upstream and will be part of upcoming
Xenomai releases.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
