bitbake do_configure failure: automake: command not found

[Matthew Barth]

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