QEMU provides a single system emulator that supports both powerpc64
and powerpc64le with a target called 'ppc64-softmmu', but it provides
a different usermode emulator for each one (with targets
'ppc64le-linux-user' and 'ppc64-linux-user').
Due to this asymmetry it is not possible to support both cases with
the single arch value used in the package file. This patch introduces
an additional value into the package configuration,
HOST_QEMU_SYS_ARCH, so that both cases can be supported.
Fixes commit d2ff457e88
and autobuilder failture
http://autobuild.buildroot.net/results/a2d63e21c3e82c36f4a975e90ed56faba18e97a5
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
[Thomas:
- Rewrap Config.in help text
- Use "depends on" rather than "select" for the audio backend options
- Slightly simplify some of the prompts for the audio backend selection
- Remove MIMIC_INSTALL_STAGING = NO, that's the default
- Use += when assigning MIMIC_DEPENDENCIES
- Remove double quotes when setting --with-audio=.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The symbol to control static compilation was renamed in 2015.02, but missed
when swupdate was added.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The EFL Wayland support was removed with commit [1] since the dependecy
on libdrm was missing. Also it requires OpenGL ES with EGL, Evas DRM
and Evas GLES DRM support [2].
As stated in configure, Evas GLES DRM engine support (gl_drm) depends
on wayland-client to build (wayland-client >= 1.8.0).
So, enable gl_drm only when wayland support is selected.
[1] 4f04be1659
[2] https://www.enlightenment.org/about-wayland
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Pierre Floury <devpfl@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
drm can be used without compositor, just like it was with
the framebuffer for standalone applications
As stated in configure.ac, libdrm support needs libdrm, elput,
libxkbcommon and libgbm.
libgbm is only provided by mesa3d package when OpenGL EGL support is
enabled, so add a direct dependency on mesa3d.
Rework the libxkbcommon dependency since it's now required for
elput and libdrm support.
[1] https://www.enlightenment.org/about-wayland
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Pierre Floury <devpfl@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The strict unused-const-variable checking was causing autobuilder errors
when trying to build Xen tools/libxl as the migrate_*[] arrays are not
always accessed.
To avoid the error edit the Makefile to stop all general warnings being treated
as errors, by removing the -Werror flag.
Fixes:
http://autobuild.buildroot.net/results/0e0/0e0d4aa4a05da5804821951289c0a4049b009c61/
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: add local sha256 hash as suggested by Vicente]
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Pass on INSTALL_PROGRAM to configure since starting with version 8.26
when building natively it tries to use the self-built install to
install, and when cross-compiling it expects INSTALL_PROGRAM to point to
a real install, or otherwise fails when recursively trying to expand it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add new GPLv2 license option.
Unfortunately COPYING is GPLv3, so avoid it.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since these are detected by the configure script, we should explicit
their dependencies in rpm.mk.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit adds two patches to the rpm package to fix two separate but
related build issues:
- The first patch fixes a build that occurs when rpm is built after
elfutils, but without binutils. In this case, dwarf.h is present, so
rpm enables the build of a number of additional tools. But one of
them uses bfd.h, provided by binutils, without checking for its
existence. So the first patch fixes that by checking for bfd.h
existence before enabling the tool.
Fixes:
http://autobuild.buildroot.net/results/810/810e24cab65f67d143da29c78c0f89d37a851cd7/build-end.log
- The second patch fixes a build issue that occurs when rpm is built
after both dwarf and binutils. In this case, bfd.h complains because
config.h is not included. That's a weird and silly issue in bfd.h
that the binutils developers don't want to fix, and you have to
define PACKAGE or PACKAGE_VERSION before including bfd.h to use it
outside of binutils.
Fixes:
http://autobuild.buildroot.net/results/362/362502f89631c9ba1d71906527674657ccff01ed/build-end.log
Thanks a lot to James Knight <james.knight@rockwellcollins.com> for the
initial investigation about the first issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
systemd-firstboot is never invoked since systemd's first boot detection
logic checks whether /etc/machine-id exists. Since the file is created
automatically by systemd.mk, systemd will never detect first boot and
therefore the systemd-firstboot.service unit file will never get run.
Additionally, if /etc/machine-id is removed to allow systemd-firstboot
to run, it interactively prompts for the system locale. This makes it
seem unlikely that an embedded system would want to use it.
Signed-off-by: Frank Hunleth <fhunleth@troodon-software.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The ARMv8 cores all support thumb2 instructions when running in aarch32 mode.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A number of packages use BR2_ARM_CPU_HAS_NEON to know if the target handles
aarch32 neon instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.
Notice: These cores do support neon-like instructions using a different
encoding in 64bit mode (it is a required part of ARMv8, similar to the FPU).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes:
http://autobuild.buildroot.net/results/5e6/5e67cc067a06f7364cde1a8393ea72608fe7fef1/
A number of packages use BR2_ARM_CPU_HAS_ARM to know if the target handles
classic A32 instructions, which is only true for ARMv8 cores when they are
running in 32bit mode.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The math tests are experimental at the moment and require more
adaptions before they can be enabled again.
The locale tests are not compatible with musl toolchains,
so disable them.
Use latest git version from upstream for other bugfixes.
Fixes:
http://autobuild.buildroot.net/results/74e/74e7add310797772bc51f9ea9847408a8b05d643/
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After commit 3ae07b4746 recently, efibootmgr now selects
BR2_PACKAGE_GETTEXT if the toolchain requires it.
gettext depends on wchar, so this dependency should be propagated as
well.
menuconfig currently complains loudly if you select efibootmgr, with an
error such as:
warning: (... && BR2_PACKAGE_EFIBOOTMGR ... && ) selects
BR2_PACKAGE_GETTEXT which has unmet direct dependencies
(BR2_USE_WCHAR)
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
efivar only makes sense on platforms that support UEFI.
UEFI is only supported by some architectures at the moment, being mostly
employed on platforms such as x86, x86_64 and aarch64. Some other
platforms such as MIPS and PowerPC may have some unofficial UEFI
support. UEFI is also limited to little endian architectures.
efivar was being supported in Buildroot without architecture
restrictions so far, however this has led to the creation of a number of
hacks in the recipes, mostly for architectures that are not supported by
UEFI.
In order to avoid spending more time to debug these failures and
maintaining more hacks for unsupported architectures, efivar can be
restricted to that platforms where it makes sense and where it is more
likely to receive some testing and actual usage.
The existing hacks for the now unsupported architectures are removed,
and the dependency is propagated to efibootmgr as it depends on efivar.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uClibc support was recently added to efivar through a small
compatibility patch.
This commit updates a comment in the efivar recipe to reflect this, as
we no longer have glibc as the only supported C library.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix kernel reproducible build if a non-C locale is used on the host
system.
When building the Linux kernel, scripts/gen_initramfs_list.sh does 'date
-d"$KBUILD_BUILD_TIMESTAMP" +%s'. In linux.mk, Buildroot sets
KBUILD_BUILD_TIMESTAMP to "$(shell date -d @$(SOURCE_DATE_EPOCH))".
For example, if LANG=fr_FR.UTF-8 is defined in the host system, it does
not work:
- LC_ALL=C date -d"$(LC_ALL=C date)" : ok
- LC_ALL=C date -d"$(LC_ALL=fr_FR.UTF-8 date)" : error
LANG/LC_ALL variables exported in the main Makefiles are not passed in
the $(shell ...) sub-shells.
Signed-off-by: Jean-Baptiste Trédez <jean-baptiste.tredez@basystemes.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A recent change in uClibc-ng removed the MADV_* definitions for
madvise(), but kept the madvise() function itself. This defeats the
logic used in madplay: it checks if madvise() is available, and if it
is, uses it and assumes the MADV_* definitions exist.
This inconsistency has been reported to upstream uClibc-ng, but in the
mean time, we can simply tell madplay to not use madvise(), which is
anyway useless on noMMU platforms.
Fixes:
http://autobuild.buildroot.net/results/3291554ea013e5f4a8f3447e10e664dffa8b131b/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
