buildroot, branch 2016.08

Update for 2016.08

2016-09-01T09:30:19+00:00

Signed-off-by: Peter Korsgaard

mpd: add optional support for libshout

2016-08-31T22:18:27+00:00

Signed-off-by: Peter Korsgaard

libshout: add optional openssl support

2016-08-31T22:18:27+00:00

Signed-off-by: Peter Korsgaard

package/libshout: add patches to fix static linking

2016-08-31T22:17:54+00:00

This series includes two patches to fix static linking with libshout. The first patch fixes two typos resulting in an uninterpretable library propagation and is mainly needed for the follow-up patch. The second patch makes sure that `@SHOUT_REQUIRES@` and therefore `Requires.private` includes ssl as `Requires.private` defines a list of private packages required by this package but not exposed to applications. Note that autoreconf is enabled as the first patch touches configure.ac. Fixes: http://autobuild.buildroot.net/results/b82/b82408fccbf816575125dcc1a1de7260f66f62e8/ http://autobuild.buildroot.net/results/360/3605750023267e4cd35d98451bd283f9e70a6106/ http://autobuild.buildroot.net/results/03b/03b98b313dd6ed2909607cdc0c4f6fb87be3ccfe/ http://autobuild.buildroot.net/results/70b/70ba47e04d1fc0d2379bf1ac7aab4c52d6193001/ [Peter: fix libssl .pc reference, fix typo] Signed-off-by: Jörg Krause Signed-off-by: Peter Korsgaard

package/luajit: disable for mips{32,64}r6

2016-08-31T21:31:41+00:00

LuaJIT does not have support for MIPS Release 6 [1]. If LuaJIT is invoked with the option `-b -a mips` to save the bytecode for the MIPS architecture it generates object files with the MIPS32 Release 1 instruction set. GCC added support for MIPS32R6 in version 5. However, object files for MIPS32R1 cannot be linked with object for MIPS32R6. That's why building the package luvi fails for MIPS32R6, where object files created with GCC are linked with object files created with LuaJIT with the following linker error: ``` linking mips:isa32 module with previous mips:isa32r6 modules ``` Disable LuaJIT for MIPS32 and MIPS64 R6 to fix the build issue with the luvi package. Fixes: http://autobuild.buildroot.net/results/e01/e017671c33314e5bf2d7fc4920f6c0e64a132383/ http://autobuild.buildroot.net/results/35f/35f558453c45a27367e80e9b8cbe3bd2dccbfd54/ http://autobuild.buildroot.net/results/8e0/8e001112b1678f9fb1c198c84184cd6f5fc3d004/ [1] http://www.freelists.org/post/luajit/Support-for-MIPS32r6,1 Signed-off-by: Jörg Krause Signed-off-by: Peter Korsgaard

mplayer: fix detection of X.org

2016-08-31T21:28:52+00:00

As reported in bug #8206, the mplayer configure script fails to detect the availability of X11 header/library if the X.org development packages are not installed on the build machine. This is due to the logic used by the mplayer configure script, which looks like this: for I in $(echo $extra_cflags | sed s/-I//g) /usr/include ; do if test -f "$I/X11/Xlib.h" ; then _x11_headers="yes" So, in other words, it: 1/ Parses the --extra-cflags option, and finds the -I options in there. 2/ Looks in /usr/include Since $(STAGING_DIR)/usr/include is in the compiler built-in search path for headers, we currently don't explicitly pass it in --extra-cflags, so mplayer only looks in /usr/include. If you have X11 headers there thanks to being installed on your build machine, everything works fine (the rest of the build logic really uses the headers and libraries of the cross-compiler). But if you don't have X11 headers in /usr/include, the configure scripts assumes X11 is not available. Since fixing the hand-written configure script of mplayer, hosted in a Subversion repository, is beyond sanity, we simply work around this problem by passing the appropriate -I$(STAGING_DIR)/usr/include option in --extra-cflags. Before this patch, during the configure script: Checking for X11 headers presence ... no (check if the dev(el) packages are installed) Checking for X11 ... no (check if the dev(el) packages are installed) And then, the mplayer binary: 0x00000001 (NEEDED) Shared library: [librt.so.0] 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.0] 0x00000001 (NEEDED) Shared library: [libm.so.0] 0x00000001 (NEEDED) Shared library: [libc.so.0] With this patch, during the configure script: Checking for X11 headers presence ... yes Checking for X11 ... yes And then, the mplayer binary: 0x00000001 (NEEDED) Shared library: [librt.so.0] 0x00000001 (NEEDED) Shared library: [libz.so.1] 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.0] 0x00000001 (NEEDED) Shared library: [libm.so.0] 0x00000001 (NEEDED) Shared library: [libXext.so.6] 0x00000001 (NEEDED) Shared library: [libX11.so.6] 0x00000001 (NEEDED) Shared library: [libXinerama.so.1] 0x00000001 (NEEDED) Shared library: [libXxf86vm.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.0] Fixes bug #8206 Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

toolchain: Bump ARC tools to arc-2016.09-eng010

2016-08-31T07:32:29+00:00

As described at: 4520524ba055706236db9f00dd79f1b2e2e87fde this commit continues a series of updates of ARC tools. This time we're updating tools to arc-2016.09-eng010. This engenering build contains different fixes done to TLS and PIE features. Appropriate custom patches are removed as they have been added to eng010. We still keep GDB as it is of arc-2016.03 release because there're some issues we'd like to resolve before releasing it to wider audience. So again note this is next engineering builds of arc-2016.09 series and it might have all kinds of breakages, please don't use it for production builds. Signed-off-by: Vlad Zakharov Signed-off-by: Peter Korsgaard

Update for 2016.08-rc3

2016-08-30T06:18:50+00:00

Signed-off-by: Peter Korsgaard

zynq: enable BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG

2016-08-29T21:29:37+00:00

The recent U-Boot adopts Kconfig for its configuration system. Signed-off-by: Masahiro Yamada Reviewed-by: Matt Weber Signed-off-by: Peter Korsgaard

libaio: allow building on static-only configurations

2016-08-29T21:24:50+00:00

This commit adds a simple patch to the libaio build system that allows it to be used on static-only configurations. It is probably easier to fix this than to propagate the !BR2_STATIC_LIBS dependency. Fixes: http://autobuild.buildroot.net/results/8c86402bd14a0af1b82e6e07c06531a856dd37c6/ Signed-off-by: Thomas Petazzoni Reviewed-by: Romain Naour Tested-by: Romain Naour Signed-off-by: Peter Korsgaard