gcc: fix ccache hash of patches in BR2_GLOBAL_PATCH_DIR
In commit f4682cf933, a hash of the patches applied to gcc was created
to make sure that ccache can properly detect when the toolchain has
changed. The patches applied to gcc consist of the buildroot patches in
package/gcc, but also potentially patches in BR2_GLOBAL_PATCH_DIR.
However, the path to the patches in BR2_GLOBAL_PATCH_DIR was corrected
incorrectly, because it misses a /. So instead of:
$(BR2_GLOBAL_PATCH_DIR)/gcc-initial/*.patch
it would look for
$(BR2_GLOBAL_PATCH_DIR)gcc-initial/*.patch
In other words, if BR2_GLOBAL_PATCH_DIR doesn't end with /, the patches
in BR2_GLOBAL_PATCH_DIR are not taken into account in the ccache hash.
To fix, add the missing /
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: He Chunhui <hchunhui@mail.ustc.edu.cn> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Gary Bisson [Wed, 13 Apr 2016 13:40:35 +0000 (15:40 +0200)]
qt5webkit: restore package
Although this package has been removed from the official release
packages since Qt5.6.0, it is still available for users to build
it from source. This is useful for platforms without GPU since its
successor (QtWebEngine) requires OpenGL support.
The package now matches the community-based meta-qt5 Yocto layer,
using the exact same revision of the qtwebkit source from github:
https://github.com/meta-qt5/meta-qt5/commit/e434995a
Here is the project source tree:
https://github.com/qtproject/qtwebkit
All the patches have been pulled from Yocto as well.
Since we are now using the source from the git repository, we need
to create an empty .git/ folder to force the headers re-generation.
https://github.com/meta-qt5/meta-qt5/blob/jethro/recipes-qt/qt5/qt5.inc#L33
Note that GPLv3 license option has been added with this release.
Reviewed-by: Julien Corjon <corjon.j@ecagroup.com> Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
[Thomas: fix license to be LGPLv2.1+, not LGPLv2+.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Max Filippov [Fri, 1 Apr 2016 09:22:03 +0000 (12:22 +0300)]
configs/qemu_xtensa_lx60_defconfig: switch to dc233c
dc232b is MMUv2 core, dc233c is very similar MMUv3 core. MMUv3 is the
latest full MMU for xtensa, which allows running both MMU and noMMU
linux variants.
Update configuration overlay and linux config file.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Tested-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current Buildroot defconfigs for Raspberry Pi and Raspberry Pi 2
instantiate a console on tty1, which appears on HDMI. Add a console on
the serial port (ttyAMA0) to be more consistent with other defconfigs
and provide a better out-of-the-box experience to users used to have a
serial console from Buildroot defconfigs.
This requires three changes:
1. have two 'console=' entries in the kernel command line: tty1,
then ttyAMA0;
2. change BR2_TARGET_GENERIC_GETTY_PORT to "console", so it starts
a getty on the last console= passed to the kernel, ttyAMA0;
3. add a new getty on tty1 to the generated inittab.
Step 2 is actually obtained by removing BR2_TARGET_GENERIC_GETTY_PORT
entirely from the defconfigs, since "console" is the default value.
Step 3 requires a post-build script since the Buildroot makefiles can
configure only one console.
Note: instead of simply adding a new getty on ttyAMA0 (which would
work) this patch actually changes BR2_TARGET_GENERIC_GETTY_PORT to
instantiate a console on UART, then adds back tty1 via
post-build.sh. This is done only to avoid the "GENERIC_SERIAL" comment
where we instantiate an HDMI console, then instantiate a really-serial
console on another line.
Signed-off-by: Samuel Martin <s.martin49@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Gary Bisson [Wed, 13 Apr 2016 10:40:52 +0000 (12:40 +0200)]
imx-uuc: new package
This package provides the Universal Adapter user-space utility that is
used to receive commands from the Manufacturing Tool using the Freescale
UTP Protocol.
It requires a Freescale/NXP kernels whose configuration contains the
CONFIG_FSL_UTP option.
The /fat file is provided as a bootargs to the g_mass_storage driver
from U-Boot, see:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/include/
configs/mx6sabre_common.h?h=imx_v2015.04_3.14.52_1.1.0_ga#n116
Init scripts are provided so that the tool starts automatically at
bootup.
Tested on Nitrogen6_MAX + MFGTools.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
[Thomas:
- test return value from start-stop⁻daemon in init script, and
reindent the init script
- fix dependency of the comment
- rewrap Config.in help text.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds freeswitch without any configured modules and with a
minimal set of non-optional dependencies. All other dependencies and
modules will be added by further patches in this series.
Please note that freeswitch source repo bundles some libraries which
are also available as buildroot packages. The freeswitch build system
does not allow to use system libraries in these cases:
The reason are patches to these packages by the freeswitch project
which are not yet upstream. There is an open JIRA report for this
situation:
https://freeswitch.org/jira/si/jira.issueviews:issue-html/FS-353/FS-353.html
More historic infos can be found here:
http://article.gmane.org/gmane.comp.telephony.freeswitch.devel/2715
https://freeswitch.org/the-missing-link/
Disable USB support when CUPS disabled, otherwise host build breaks.
Fixes following autobuild error:
http://autobuild.buildroot.net/results/081b3be918ac1eaa8cfbc5919e00bc1ea267c1df/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas:
- use Git formatted patch, cherry-picked from upstream
- remove --without-libusb, not needed.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Turns out that the custom help is not available when the $(O) directory
has not been configure yet (i.e. when there is no .config already
filled).
Rather than trying to work around this limitation with dirty hacks, just
revert this feature. After all, this will not prevent an external.mk
from providing custom help anyway; it's just not gonna be advertised nor
displayed with the main help.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Jérôme Pouiller <jezz@sysmic.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Turns out that the custom help is not available when the $(O) directory
has not been configure yet (i.e. when there is no .config already
filled).
Rather than trying to work around this limitation with dirty hacks, just
revert this feature. After all, this will not prevent an external.mk
from providing custom help anyway; it's just not gonna be advertised nor
displayed with the main help.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Jérôme Pouiller <jezz@sysmic.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Lee Jones [Fri, 15 Apr 2016 21:02:20 +0000 (23:02 +0200)]
configs/stm32f469_disco: new configuration for STM32F469 Discovery board
Similar to stm32f429_disco, this commit adds a configuration for the
Cortex-M4 based STM32F469 platform.
It requires a few kernel patches, which have already been submitted
upstream, as well as a small OpenOCD patch. Besides that, it re-uses
most of what has been added for the STM32F429 platform.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[Thomas:
- squash multiple patches from Lee Jones into one
- improve the readme.txt file
- sync the defconfig with the adaptations made to the stm32f429
configuration.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Lee Jones [Fri, 15 Apr 2016 21:02:19 +0000 (23:02 +0200)]
configs/stm32f429_disco: new configuration for STM32F429 Discovery board
This commit adds a defconfig for the STM32F429 platform, which is
based on a Cortex-M4 core from ST Microelectronics. It is therefore
the first noMMU ARM platform supported in Buildroot.
This commit includes some files that will be common to several STM32
platforms (hence in board/stmicroelectronics) and some files that are
specific to the STM32F429 (hence in
board/stmicroelectronics/stm32f429-disco). More specifically, this
commit adds:
- A minimal Busybox configuration, which is small enough to boot
without causing OOM on such small noMMU platforms. The resulting
Busybox, statically linked with uClibc-ng, weights around 220
KB. For now, this file is located in board/stmicroelectronics/, but
we might consider moving it to package/busybox/ in the future if
needed.
- A post-build script that removes the mounting of /dev/pts (not
enabled in the kernel and not very useful for a system that has no
network and no X), and removes the network related init script and
configuration files (no network support).
- A flash.sh script, to perform the right OpenOCD invocations to
reflash the board.
- One small kernel patch to adjust the kernel command line in the
Device Tree, since it's the only way to do so.
- The usual readme.txt file.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
[Thomas:
- squashed multiple patches from Lee Jones together
- added the minimal Busybox configuration
- added the post-build script
- improved the flashing script to not hardcode the location of the
output directory
- add the small kernel patch
- improve the readme.txt file
- test on HW the resulting image, after using the internal toolchain.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Fri, 15 Apr 2016 21:02:18 +0000 (23:02 +0200)]
afboot-stm32: use the Buildroot toolchain
By default, the afboot-stm32 Makefile uses "CROSS_COMPILE =
arm-none-eabi-". Since I had such a toolchain installed on my system
when testing afboot-stm32, I didn't realize it wasn't using the
Buildroot toolchain.
However, using the Buildroot toolchain doesn't immediately works for
FLAT toolchains, as gcc automatically wants to create a FLAT
binary. So we need to adjust the afboot-stm32 Makefile to use directly
'ld' and not 'gcc' when linking.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni [Fri, 15 Apr 2016 21:02:17 +0000 (23:02 +0200)]
elf2flt: use new upstream site and bump version
The uClinux developers now have a Github with elf2flt code, with an
upstream that is again active. Let's switch to this upstream, which
has built-in support for ARM noMMU, contributed by Waldemar.
Since we're now fetching from github, a hash file is added as well.
Finally, we disable -Werror to avoid build issues caused by warnings.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The yajl build system contains a race condition, which gets triggered by
high BR2_JLEVEL settings - It tries to link the executable gen-extra-close
against the shared libyajl before it is created:
[ 21%] Linking C executable gen-extra-close
[ 26%] Building C object src/CMakeFiles/yajl_s.dir/yajl_buf.c.o
/home/test/autobuild/instance-3/output/host/opt/ext-toolchain/bfin-uclinux/bfin-uclinux/bin/ld.real: cannot find -lyajl
Fix this issue by linking gen-extra-close against the shared library in a shared
build and the static library otherwise.
Apply this to all other build targets from yail who are linking against the
library, too.
Unfortunately gdk-pixbuf-query-loaders doesn't understand cross loaders
to update the cache, hence we can't use the host variant against target
loaders since it will output an effectively empty cache, causing runtime
failure of libgtk when finding icons.
So make host-gdk-pixbuf functionally equivalent to the target gdk-pixbuf
so we can run gdk-pixbuf-query-loaders against the host plugins and just
strip the host directory to make it runtime-compatible (like was done
before for the target directory).
This is still better than trying to update at runtime, since that would
require a writable loaders.cache file in tmpfs or rw filesystem, not to
mention the associated additional startup time.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 1e5bc05a04d (configs: freescale_imx6*: bump version to
3.14.52-1.1.0_ga) updated the kernel but forgot to change the kernel headers
version to match.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
connman: add patch to fix build with headers >= 4.5
Add a patch from Gentoo that fixes the build on linux headers >= 4.5
The probem arises from an incompatibility in newer headers when both
net/if.h and linux/if.h are included in the same source.
See https://bugs.gentoo.org/show_bug.cgi?id=577584
Nicolas Dichtel [Thu, 14 Apr 2016 14:58:32 +0000 (16:58 +0200)]
Makefile: reset LD and AR environment variables
The goal is to fix the compilation of perf (from linux) when LD or AR
variables are inherited from the environment.
After the linux upstream commits 5ef7bbb09f7b ("perf tools: Allow to
specify custom linker command") and 3c71ba3f80bb ("perf tools: Really allow
to specify custom CC, AR or LD") CC, AR, and LD variables are not overridden
if they are inherited.
In case of a cross compilation, it results in an inconsistent state: CC is
overridden but not LD and AR.
`-ldl` option is used unconditionally in `QMAKE_LIBS_DYNLOAD` while libdl is
not supported when libc is static. As the value of `QMAKE_LIBS_DYNLOAD` goes
into 'Libs.private' field of the pkgconfig files created by qmake, static
linking with qt will fail with:
/usr/bin/ld: cannot find -ldl
Fix this issue by adding a build test to configure to check if libdl is
supported. `QMAKE_LIBS_DYNLOAD` in "src/corelib/plugin/plugin.pri" is now used
only if libdl is available.
This helps to make sure that QT_SOCKLEN_T is defined to be 'int' only for legacy
glibc < 2 and not also for other libraries which may define it as per standards
but are not glibc, e.g. musl.
Fixes the following build error:
In file included from ../../include/QtNetwork/private/qnet_unix_p.h:1:0,
from kernel/qnetworkinterface_unix.cpp:46:
../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h: In function 'int qt_safe_accept(int, sockaddr*, int*, int)':
../../include/QtNetwork/private/../../../src/network/socket/qnet_unix_p.h:121:76: error: invalid conversion from 'int*' to 'socklen_t* {aka unsigned int*}' [-fpermissive]
There is a new conflict between Linux header (linux/if.h)
and C library header (net/if.h) introduced by this commit
to the Linux kernel: 1ffad83dffd675cd742286ae82dca7d746cb0da8
Mikko Rapeli is working on a solution, but it requires
changes to the Linux kernel and C library.
For now I would just disable the iptables feature in Strongswan.
src/Error.cpp: In static member function 'static std::string Poco::Error::getMessage(int)':
src/Error.cpp:71:55: error: invalid conversion from 'int' to 'const char*' [-fpermissive]
return std::string(strerror_r(errorCode, errmsg, 256));
There are 2 flavors of `strerror_r`, a GNU which returns a string and a POSIX
version which returns an int.
When the POSIX and GNU API collides musl always provides the POSIX API. That
being the case for `strerror_r` musl does only support the POSIX version,
despite of `_GNU_SOURCE`.
Also:
- add a hash file.
- replace patch #0002 by passing the DEFAULT_TARGET to poco
- remove patch #0003 as it is obsolet since upstream commit 010f7a5370be450109f1726e39d5b193e63a6373
- remove patch #0004 which is applied upstream
- remove patch #0005 which is fixed by upstream different
Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>