* [Buildroot] vboot-utils issue in Buildroot
@ 2017-11-06 16:24 Thomas Petazzoni
[not found] ` <20171106184840.GA28366@latitude.localdomain>
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Petazzoni @ 2017-11-06 16:24 UTC (permalink / raw)
To: buildroot
Hello Alexey,
I'm contacting you because you are listed in Buildroot's DEVELOPERS
file for the vboot-utils package.
We recently started to have build failures of host-vboot-utils:
http://autobuild.buildroot.net/?reason=host-vboot-utils-bbdd62f9b030db7ad8eef789aaf58a7ff9a25656
These all happen because we have enabled a new ppc64le build machine.
To be clear: it is not about building *for* a ppc64le target, it's
about the machine running Buildroot using a ppc64le processor.
The build fails with:
make[2]: *** No rule to make target `/home/peko/autobuild/instance-0/output/build/host-vboot-utils-bbdd62f9b030db7ad8eef789aaf58a7ff9a25656/build/host/arch/ppc64le/lib/crossystem_arch.o', needed by `/home/peko/autobuild/instance-0/output/build/host-vboot-utils-bbdd62f9b030db7ad8eef789aaf58a7ff9a25656/build/libvboot_util.a'. Stop.
And obviously, host/arch/ppc64le/lib/crossystem_arch.c doesn't exist in
the vboot-utils source code, there's only a file for x86, x86_64, arm
and mips.
However, reading the logic in Makefile, it is not entirely clear what
this list of supported architectures is. It does this:
_machname := $(shell uname -m)
HOST_ARCH ?= ${_machname}
# ARCH and/or FIRMWARE_ARCH are defined by the Chromium OS ebuild.
# Pick a sane target architecture if none is defined.
ifeq (${ARCH},)
ARCH := ${HOST_ARCH}
[...]
So it has some concept of HOST_ARCH vs. ARCH. But later on in the
Makefile, it apparently wants to use Qemu if ARCH != HOST_ARCH.
The problematic file being used is:
host/arch/${ARCH}/lib/crossystem_arch.c \
Could you have a look at what this architecture specific code is doing?
It's somewhat weird in a set of host utilities to have something that
would depend on the target architecture.
It would be nice to see what the right solution is, as this package is
causing a significant number of build failures at the moment.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Buildroot] vboot-utils issue in Buildroot
[not found] ` <20171106184840.GA28366@latitude.localdomain>
@ 2017-11-06 19:48 ` Thomas Petazzoni
2017-11-06 21:15 ` Alex Suykov
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Petazzoni @ 2017-11-06 19:48 UTC (permalink / raw)
To: buildroot
Hello,
Thanks for your feedback. However, please keep the mailing list in Cc.
Thanks!
On Mon, 6 Nov 2017 20:48:40 +0200, Alex Suykov wrote:
> > Could you have a look at what this architecture specific code is doing?
> > It's somewhat weird in a set of host utilities to have something that
> > would depend on the target architecture.
>
> Those are target-specific definitions for sure, so ARCH must
> be the target architecture there. I'll try to send a patch now.
Gentoo defines ARCH == HOST_ARCH. Be careful that if they are
different, vboot-utils will try to use Qemu.
> vboot-utils aren't really host-only, it's also a target package in ChromeOS
> and it fills the role of efibootmgr on PC. The code in crossystem_arch
> seems to be about boot configuration, so completely irrelevant when building
> a host package. But it always gets built.
>
> Chromeos does support cross-compiling, but I suspect no-one ever tried
> building it on a host that wasn't x86_64 or maybe arm.
But it's quite weird to have a dependency on the target architecture
when building a host tool. Looking at the ARM specific code for
example, it pokes into /proc/firmware/device-tree/, which obviously has
no chance to exist on the build machine.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Buildroot] vboot-utils issue in Buildroot
2017-11-06 19:48 ` Thomas Petazzoni
@ 2017-11-06 21:15 ` Alex Suykov
0 siblings, 0 replies; 3+ messages in thread
From: Alex Suykov @ 2017-11-06 21:15 UTC (permalink / raw)
To: buildroot
Mon, Nov 06, 2017 at 08:48:08PM +0100, Thomas Petazzoni wrote:
> Thanks for your feedback. However, please keep the mailing list in Cc.
Sorry, did not notice it was a list message. This one should go with Cc.
> But it's quite weird to have a dependency on the target architecture
> when building a host tool. Looking at the ARM specific code for
> example, it pokes into /proc/firmware/device-tree/, which obviously has
> no chance to exist on the build machine.
Here's what I think happens there: they have a common library that gets
used both for target-independent tools (futility) and target-specific
tools (crossystem). This library includes some target-specific code that
is only needed for crossystem, but gets built anyway because it's a part
of the library.
Actually within Buildroot this whole problem can be solved with a simple
patch that would delete this line:
host/arch/${ARCH}/lib/crossystem_arch.c \
crossystem seems to be the only tool that calls anything from that file,
no idea why it's a part of the library.
> Gentoo defines ARCH == HOST_ARCH. Be careful that if they are
> different, vboot-utils will try to use Qemu.
Looks like qemu is only used there for tests.
Also, the way they choose qemu command:
ifeq (${ARCH},${HOST_ARCH})
...
else
QEMU_ARCH := ${ARCH}
endif
...
QEMU_BIN = qemu-${QEMU_ARCH}
doesn't make any sense if ARCH is HOST_ARCH.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-11-06 21:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-06 16:24 [Buildroot] vboot-utils issue in Buildroot Thomas Petazzoni
[not found] ` <20171106184840.GA28366@latitude.localdomain>
2017-11-06 19:48 ` Thomas Petazzoni
2017-11-06 21:15 ` Alex Suykov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.