bitbake do_configure failure: automake: command not found

Tue Aug 21 01:48:05 AEST 2018

On Wed, Aug 8, 2018 at 2:46 PM Patrick Venture <venture at google.com> wrote:
>
> On Wed, Aug 8, 2018 at 9:31 AM, Matthew Barth <msbarth at linux.ibm.com> wrote:
> >
> >
> > On 08/08/2018 11:04 AM, Patrick Venture wrote:
> >>
> >> On Wed, Aug 8, 2018 at 8:56 AM, Matthew Barth <msbarth at linux.ibm.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 08/08/2018 09:42 AM, Patrick Venture wrote:
> >>>>
> >>>>
> >>>> I'm seeing the configure fail on a couple downstream recipes that
> >>>> essentially just build ipmi libraries now that we're merged with v2.2
> >>>> of OpenBMC.
> >>>>
> >>>> NOTE: recipe google-ipmi-ethstats-1.0-r0: task do_configure: Started
> >>>> ERROR: google-ipmi-ethstats-1.0-r0 do_configure: Function failed:
> >>>> do_configure (log file is located at
> >>>>
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/log.do_configure.8938)
> >>>> ERROR: Logfile of failure stored in:
> >>>>
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/log.do_configure.8938
> >>>> Log data follows:
> >>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
> >>>> 'arm-32', 'common-linux', 'common-glibc', 'arm-linux',
> >>>> 'arm-linux-gnueabi', 'common']
> >>>> | DEBUG: Executing shell function autotools_preconfigure
> >>>> | DEBUG: Shell function autotools_preconfigure finished
> >>>> | DEBUG: Executing python function autotools_aclocals
> >>>> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
> >>>> 'arm-32', 'common-linux', 'common-glibc', 'arm-linux',
> >>>> 'arm-linux-gnueabi', 'common']
> >>>> | DEBUG: Python function autotools_aclocals finished
> >>>> | DEBUG: Executing shell function do_configure
> >>>> |
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/run.do_configure.8938:
> >>>> 1:
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/run.do_configure.8938:
> >>>> automake: not found
> >>>> |
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/run.do_configure.8938:
> >>>> 146:
> >>>>
> >>>> /tmpfs/gbmc-sm/gbmc/build/tmp/work/armv5e-openbmc-linux-gnueabi/google-ipmi-ethstats/1.0-r0/temp/run.do_configure.8938:
> >>>> automake: not found
> >>>
> >>>
> >>>  From what's given, I'd check to see if the continuous build environment
> >>> has
> >>> the autotools installed since `automake` isnt found.
> >>
> >>
> >> So, the environment has automake and autotools-dev installed.  I also
> >> tried within a docker instance and made sure those were installed.
> >> That said, with yocto 2.3 it's not supposed to rely on what's
> >> installed in the host environment but rather rely on the native
> >> packages that come as dependencies.  Or am I mistaken?
> >>
> > Correct, yocto should include the dependencies. Is automake included within
> > openbmc/import-layers/yocto-poky/meta/recipes-devtools ?
> >
> >
> >>>
> >>>
> >>>> | WARNING: exit code 127 from a shell command.
> >>>>
> >>>> The configure.ac:
> >>>>
> >>>> # Initialization
> >>>> AC_PREREQ([2.69])
> >>>> AC_INIT([gsys-ipmi], [1.0], [https://www.google.com])
> >>>> AC_LANG([C++])
> >>>> AC_CONFIG_HEADERS([config.h])
> >>>> AM_INIT_AUTOMAKE([subdir-objects -Wall -Werror foreign dist-xz])
> >>>> AM_SILENT_RULES([yes])
> >>>> # Checks for programs.
> >>>> AC_PROG_CXX
> >>>> AM_PROG_AR
> >>>> AC_PROG_INSTALL
> >>>> AC_PROG_MAKE_SET
> >>>> # Checks for typedefs, structures, and compiler characteristics.
> >>>> AX_CXX_COMPILE_STDCXX_14([noext])
> >>>> AX_APPEND_COMPILE_FLAGS([-Wall -Werror], [CXXFLAGS])
> >>>> # Checks for libraries.
> >>>> PKG_CHECK_MODULES([SYSTEMD], [libsystemd >= 221], [],
> >>>> [AC_MSG_ERROR(["systemd required and not found"])])
> >>>> PKG_CHECK_MODULES([SDBUSPLUS], [sdbusplus], ,[AC_MSG_ERROR([The
> >>>> openbmc/sdbusplus package is required])])
> >>>> PKG_CHECK_MODULES([PHOSPHOR_LOGGING], [phosphor-logging],
> >>>> ,[AC_MSG_ERROR([The openbmc/phosphor-logging package is required])])
> >>>> PKG_CHECK_MODULES([PHOSPHOR_DBUS_INTERFACES],
> >>>> [phosphor-dbus-interfaces], [],
> >>>> [AC_MSG_ERROR(["phosphor-dbus-interfaces required and not found."])])
> >>>> AC_CHECK_HEADER(experimental/any, ,[AC_MSG_ERROR([Could not find
> >>>> experimental/any...libstdc++fs developement package required])])
> >>>> # Checks for library functions.
> >>>> LT_INIT # Required for systemd linking
> >>>> # Create configured output
> >>>> AC_CONFIG_FILES([Makefile])
> >>>> AC_OUTPUT
> >>>>
> >>>> Which looks like all the others I've seen, more or less, nothing
> >>>> special.
> >>>>
> >>>> The recipe:
> >>>>
> >>>> SUMMARY = "Ethernet Statistics OEM Command"
> >>>> DESCRIPTION = "Ethernet Statistics OEM Command"
> >>>> LICENSE = "CLOSED"
> >>>> inherit autotools pkgconfig
> >>>> inherit obmc-phosphor-ipmiprovider-symlink
> >>>> S = "${WORKDIR}/"
> >>>> SRC_URI = "file://Makefile.am \
> >>>>    file://bootstrap.sh \
> >>>>    file://configure.ac \
> >>>>    file://main.cpp \
> >>>> "
> >>>> DEPENDS += "autoconf-archive-native"
> >>>> DEPENDS += "sdbusplus"
> >>>> DEPENDS += "phosphor-logging"
> >>>> # We depend on this to be built first so we can build our providers.
> >>>> DEPENDS += "phosphor-ipmi-host"
> >>>> RDEPENDS_${PN} += "sdbusplus phosphor-dbus-interfaces"
> >>>> FILES_${PN}_append = " ${libdir}/ipmid-providers/lib*${SOLIBS}"
> >>>> FILES_${PN}_append = " ${libdir}/host-ipmid/lib*${SOLIBS}"
> >>>> FILES_${PN}_append = " ${libdir}/net-ipmid/lib*${SOLIBS}"
> >>>> FILES_${PN}-dev_append = " ${libdir}/ipmid-providers/lib*${SOLIBSDEV}
> >>>> ${libdir}/ipmid-providers/*.la"
> >>>> HOSTIPMI_PROVIDER_LIBRARY += "libethstatscmd.so"
> >>>>
> >>>> Any things to check or poke would be appreciated.  It doesn't break in
> >>>> all build environments, oddly.  Presumably with the yocto 2.3
> >>>> inclusion in OpenBMC v2.2, the host environment became less involved. >
> >>>> But when I build an image on my desktop, it builds fine.  When I run
> >>>> the same commands in our continuous build environment, it fails.
> >>>
> >>>
> >>> When you build on your desktop are you in an SDK and/or have autotools
> >>> installed in your environment already and maybe not in the continuous
> >>> build
> >>> environment? I'd start poking around for those differences.
> >>
> >>
> >> I'm not in an SDK. I'm just building the obmc-phosphor-image from a
> >> clean check-out of the meta layers.  The command I'm running locally
> >> and the environment for the continuous build are the same in terms of
> >> commands and configuration, but different in terms of locally
> >> installed packages.  Which, per the above, I thought that was no
> >> longer a factor.
> >>
> >>>
> >>>>
> >>>> Patrick
> >>>>
> >>>
> >>> Matt
> >>>
> >>
> >
>
> Tried:
>
> + bitbake-layers show-recipes
> + grep -A1 automake
> automake:
>   meta                 1.15.1
>
> So we're seeing it's available...

So, Kun was able to shake out that it looks like something is
sometimes changing variables that are impacting various recipes that
use automake in some race condition.  Details, are not yet hashed out,
but I'll keep this thread updated.