gst1-plugins-bad: Add bug URL for the opencv modules issue

A bug has been reported upstream to fix this issue properly, and a
GStreamer developer agreed with our proposal. We add the bug URL to
comments on Config.in to let the interested users follow the progress of
this issue.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
vlc: needs toolchain with c++ support

Signed-off-by: Simon Dawson <spdawson@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
lua: remove LUA_INSTALLED_FILES

Useless since the uninstall commands were removed in eb7bd9ef

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
lua: refactor install steps

since the comeback of version in module path (see commit ccd68a51)
the upstream Makefiles are usable for install.

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
lua: handles BR2_PREFER_STATIC_LIB

fix compilation with Blackfin FLAT

see http://autobuild.buildroot.net/results/b41/b4146bf821d59f694546f6e3a341394cc8fa43ce/

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
luarocks: never wraps script

this config prevents the introduction of some HOST_DIR paths on target

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cegui06: need dynamic library support

Fixes:

  http://autobuild.buildroot.org/results/caf/caf421629f4465cd347dc40af0b559c4d9b0c09f/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
luajit: pass LDCONFIG=true to make sure dynamic library links are created

To install its shared library, the luajit Makefile does:

        cd src && test -f $(FILE_SO) && \
          $(INSTALL_X) $(FILE_SO) $(INSTALL_DYN) && \
          $(LDCONFIG) $(INSTALL_LIB) && \
          $(SYMLINK) $(INSTALL_SONAME) $(INSTALL_SHORT1) && \
          $(SYMLINK) $(INSTALL_SONAME) $(INSTALL_SHORT2) || :

This means that if ldconfig doesn't work or isn't available on the
system, it won't create the libluajit-5.1.so -> libluajit-5.1.so.5.2.0
symbolic link.

Not having this symbolic link prevents lua-ev from finding the shared
version of the luajit library, and it fallbacks to using the
libluajit.a static library. However, this static library is not built
with -fPIC, so using it within a shared library doesn't work, and
leads to build failures on architectures that really do want to have
non-fPIC code into a shared library, such as x86-64.

By passing LDCONFIG=true during the installation steps of luajit, we
ensure that the symbolic links are created, which allows lua-ev to
detect the shared library properly, making everybody happy.

Investigation conducted with Samuel Martin. Thanks!

Fixes:

  http://autobuild.buildroot.org/results/41c/41c8bb9cf91a86908a150dae27726136cb56f5b7/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
libxml2: do not detect zlib/lzma when not available

The host-libxml2 package does not depend on zlib or lzma, but may
detect versions available on the host. This can cause problems in the
following situation:

 1 host-libxml2 is built, finds an available lzma library in the
   system, enables lzma support by using it.

 2 host-xz is built, which installs a different version of the lzma
   library into $(HOST_DIR)

 3 host-libxslt is built, tries to link against libxml2, which fails
   because now the visible lzma library is the one from
   $(HOST_DIR)/usr/lib and no longer the one libxml2 was built agains.

To fix this, this patch passes --without-zlib and --without-lzma to
the host package.

In addition, since the target variant of libxml2 does not have
provisions to depend on the target lzma, we also pass --without-lzma
for the target variant. The case of zlib for the target was already
properly taken into account.

Fixes:

  http://autobuild.buildroot.org/results/6dc/6dcef647eb0f0db7de3f34194eb15ceebc645b39/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gcc: fix xtensa overlay application

gcc build scripts use wrong variable name to specify xtensa overlay
application command. As a result gcc is built with the default overlay,
which leads to obscure failures later in the build process.

xtensa toolchain needs an additional configuration for a specific core
variant we're building for. This configuration is called 'overlay' and
is an archive with files for binutils, gcc and gdb that replace
corresponding files in toolchain components.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ramsmp: not available on !MMU, needs fork

Fixes:

  http://autobuild.buildroot.org/results/aaa/aaa7f8e5ec72ce69805d6c1a5cde5ff47e1c118e/

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gstreamer{,1}: fix unaligned access detection for microblaze

Fixes http://autobuild.buildroot.net/results/f49/f4914bb3999c8a7a0c0a2afdac5de40fb9058372/

Similar to the existing handling for avr32 and xtensa. Also add it for
gstreamer1 for good measure as it was missing there as well.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>