bitbake do_configure failure: automake: command not found

[Patrick Venture]

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?

>
>
>> | 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
>