Bug 13375

We noticed a strange problem when building one of our custom recipes. The autotools.bbclass does not fill in CONFIG_SITE consistently across different tasks.

We have a custom lua recipe which uses a SYSROOT_PREPROCESS_FUNCS function to drop a config_site file into ${TARGET_SYS}_config_site.d with some autoconf cache variables prepopulated, to help the AX_PROG_LUA macro find lua interpreter paths without executing the target interpreter:

SYSROOT_PREPROCESS_FUNCS += "do_siteconfig"
do_siteconfig() {
    mkdir -p ${SYSROOT_DESTDIR}${datadir}/${TARGET_SYS}_config_site.d
    cat >${SYSROOT_DESTDIR}${datadir}/${TARGET_SYS}_config_site.d/lua_config <<EOF
ax_cv_pathless_LUA=lua
ax_cv_lua_version=5.1
ax_cv_lua_platform=unknown
ax_cv_lua_luadir=${datadir}/lua/5.1
ax_cv_lua_luaexecdir=${libdir}/lua/5.1
EOF
}

Then we have a recipe for a proprietary package which depends on lua and uses AX_PROG_LUA in its configure.ac. The autotools.bbclass populates CONFIG_SITE based on what it finds in the sysroot, and it correctly sees the lua_config file in addition to all the others, when do_configure runs the ./configure script.

  configure: loading site script .../poky/meta/site/endian-little
  configure: loading site script .../poky/meta/site/common-linux
  configure: loading site script .../poky/meta/site/common-glibc
  configure: loading site script .../poky/meta/site/x86_64-linux
  configure: loading site script .../poky/meta/site/common
  configure: loading site script .../poky/../meta-openembedded/meta-networking/site/endian-little
  configure: loading site script build/tmp-glibc/work/puma-64-og-linux/ogconfig/1.0+git999-r0/recipe-sysroot/usr/share/x86_64-og-linux_config_site.d/glibc_config
  configure: loading site script build/tmp-glibc/work/puma-64-og-linux/ogconfig/1.0+git999-r0/recipe-sysroot/usr/share/x86_64-og-linux_config_site.d/lua_config
  configure: loading site script build/tmp-glibc/work/puma-64-og-linux/ogconfig/1.0+git999-r0/recipe-sysroot/usr/share/x86_64-og-linux_config_site.d/ncurses_config
  [...]

So far so good.

However, for local development of the proprietary package, we use externalsrc.bbclass and set EXTERNALSRC to point at a git checkout. The recipe has a native variant, so bitbake will build both $OURPACKAGE and $OURPACKAGE-native -- often concurrently.

As a consequence, it can happen that bitbake will do autoreconf for one variant of the recipe while the other variant has already completed do_configure and has moved onto do_compile or do_install. The autoreconf happens in the same source tree, even though the build directories are separate. That means the configure script in the source tree will be touched by both recipes variants, possibly while each is building.

automake has a rule to invoke ./config.status --recheck if the configure script changed since it was run. And so that rule can be triggered in do_compile or do_install for the concurrently running recipes.

Normally ./config.status --recheck just does a quick run through the cache variables to ensure nothing has changed and then the build continues. And nothing should have changed because bitbake gives us a consistent build environment. But something *does* change: the CONFIG_SITE environment variable is different in do_compile and do_install. It doesn't include any files from ${TARGET_SYS}_config_site.d, and so ./config.status --recheck fails.

The reason seems to be because CONFIG_SITE is populated in two different ways in autotools.bbclass. Globally there is:

  # Space separated list of shell scripts with variables defined to supply test
  # results for autoconf tests we cannot run at build time.
  export CONFIG_SITE = "${@siteinfo_get_files(d)}"

This is calling siteinfo_get_files with sysrootcache=False which intentionally omits everything from ${TARGET_SYS}_config_site.d in the sysroot. The variable is populated differently for do_configure:

  do_configure[prefuncs] += "autotools_preconfigure autotools_aclocals ${EXTRACONFFUNCS}"

  [...]

  python autotools_aclocals () {
      # Refresh variable with cache files
      d.setVar("CONFIG_SITE", siteinfo_get_files(d, sysrootcache=True))
  }

Here it passes sysrootcache=True and so it correctly picks up files from ${TARGET_SYS}_config_site.d in the sysroot.

The end result is that CONFIG_SITE is correct for do_configure but not for do_compile and do_install.