[Buildroot] vboot-utils issue in Buildroot

[Buildroot] vboot-utils issue in Buildroot

[Thomas Petazzoni]

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

[Buildroot] vboot-utils issue in Buildroot

[Thomas Petazzoni]

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

[Buildroot] vboot-utils issue in Buildroot

[Alex Suykov]

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.