Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: adjust to the changes in the infra, fix typos.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This new waf-package infrastructure simplifies writing waf-based
packages. It can be used by our six current such packages, plus a
later-incoming one by Romain.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- rename <pkg>_BUNDLED_WAF to <pkg>_NEEDS_EXTERNAL_WAF, which
involves inverting the meaning of the boolean.
- always add the host-python dependency
- add a default value for <pkg>_NEEDS_EXTERNAL_WAF (defaults to NO)
- remove the unneeded <pkg>_MAKE related definitions.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
host-waf will be used by waf-based packages that do not include it in
their release tarballs, like mpv.
mpv is currently the only case we have, but with the upcoming
waf-package infra, having host-waf available just makes the infra
complete from the onset.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@openwide.fr>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas: drop dependency on host-python, it's really a runtime dependency.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
PPC altivec vectorization triggers a bug when compiling with -std=c++11
because "bool" is redefined in altivec.h.
src/emucore/Event.hxx:112:23: error: cannot convert ‘bool’ to ‘__vector(4) __bool int’ in assignment
myKeyTable[i] = false;
^
Acording to a bug report in GCC [1], "You need to use -std=g++11 or
undefine bool after the include of altivec.h as context sensitive
keywords is not part of the C++11 standard".
So let's compile with -std=gnu++11 by default.
Tested on ARM, x86 and PPC.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241#c3
Fixes:
http://autobuild.buildroot.net/results/0970d2c8e1787ceffc46b589522e53d52675e03chttp://autobuild.buildroot.net/results/ec1bc57675b6e53af0cd33d7b99cd2e3bf5d9d7e
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Change "foo" references to "libfoo" in section that defines variables
explicitly stated to relate to a "libfoo" package.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-rc2.
This change contains a set of minor fixes and updates.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When BR2_STRIP is set to none, a dummy 'true' app is used instead of
strip utility. However, kexec package always requires a real strip
executable as it is used to generate intermediate files during the build
process.
If 'true' is used the build system runs the following command:
true --strip-debug -o purgatory/purgatory.ro purgatory/purgatory.ro.sym
which obviously doesn't do anything useful and the build later fails
with:
bin/bin-to-hex purgatory < purgatory/purgatory.ro > kexec/purgatory.c
/bin/sh: purgatory/purgatory.ro: No such file or directory
kexec/Makefile:7: recipe for target 'kexec/purgatory.c' failed
make[2]: *** [kexec/purgatory.c] Error 1
To resolve it always specify STRIP=$(CROSS_COMPILE)strip, regardless of
buildroot configuration.
[Peter: add a comment explaining why this is done]
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Also add a sha256 hash since upstream only provides one weak hash.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
My local 'next' branch was not uptodate, so the previous merge was missing
the most recent changes.
Thanks to François Perrad for noticing.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The 0.12.3 bump forgot to update the download hash and remove the now
upstreamed patch, breaking the build.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Switch from RPM5's implementation to rpm.org's more active stream [1].
The history of RPM and the common RPM5-fork is covered in an LWN article
"Who maintains RPM?" [2]. Since rpm.org's implementation is used/
maintained on most RPM-based distributions as well as a series of other
minor details (see [3]), the switch is being made.
[1]: http://lists.buildroot.org/pipermail/buildroot/2015-August/137580.html
[2]: https://lwn.net/Articles/196523/
[3]: https://patchwork.ozlabs.org/patch/668151/
Signed-off-by: James Knight <james.knight@rockwellcollins.com>
[Thomas: adjust licensing.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This reverts commit 71d9b0c1f0.
Now that -mauto-litpools is in TARGET_ABI when building for xtensa, -O0
builds succeed, so this workaround is no longer needed.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Zero overhead loop optimization pass may incorrectly put start of the
loop between a call and its CALL_ARG_LOCATION note, resulting in the
following build error:
../src/pjlib-test/thread.c: In function 'thread_test':
../src/pjlib-test/thread.c:328:1: internal compiler error: in
dwarf2out_var_location, at dwarf2out.c:21846
Fixes:
http://autobuild.buildroot.net/results/d919e1276ce1d39b4b3eb09937927d5959cd69a3/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes gcc build for xtensa configurations with call0 ABI.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream provides xz tarballs instead of bz2, so make the switch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Drop sha256 hash. The combination of md5 and sha1 hashes is enough.
Add a patch that fixes a build failure due to using the compiler of the
host machine. The patch has been submitted as a pull request:
https://github.com/lttng/lttng-ust/pull/41
Release notes:
https://lists.lttng.org/pipermail/lttng-dev/2016-November/026761.html
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Drop sha256 hash. The combination of md5 and sha1 hashes is enough.
Release notes:
https://lists.lttng.org/pipermail/lttng-dev/2016-November/026762.html
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with Qemu v2.7.0 and the qemu_aarch64_virt_defconfig
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested with qemu-2.4.1-11.fc23 and the qemu_arm_vexpress_defconfig
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that the madvise defines are disabled for noMMU targets,
architectures with MMU and noMMU support as ARM are failing to compile
in noMMU mode, since the defines are used internally in posix_madvise.c.
Disable compilation for posix_madvise() for noMMU.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When generating the environment image the target endianess should
be taken in account for CRC calculation purposes. For big endian
targets the -b flag should be passed to the mkenvimage tool.
Signed-off-by: Tiago Brusamarello <tiago.brusamarello@datacom.ind.br>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
