V2.5 libdmx config failure

I’m building for the Apalis iMX6Q, with a few extra layers, notably meta-fsl-arm, meta-fsl-arm-extra among others.

V2.4 built fine, but I need a kernel version 4.0 at least for the TW6869 driver (I think).

I upgraded to V2.5 which uses fido, Yocto 1.8. Then I ‘repo sync’ to git new. I can’t get past libdmx-1.1.3-r0 configure, always failing. Log:

DEBUG: Executing python function sysroot_cleansstate
DEBUG: Python function sysroot_cleansstate finished
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_copy_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_copy_aclocals finished
DEBUG: Executing shell function do_configure
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey@redhat.com>
       and Alexandre Duret-Lutz <adl@gnu.org>.
AUTOV is 1
NOTE: Executing ACLOCAL="aclocal --system-acdir=/home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/build/aclocal-copy/" autoreconf --verbose --install --force --exclude=autopoint
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --system-acdir=/home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/build/aclocal-copy/ --force 
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /home/gumstix/oe-core/build/out-glibc/sysroots/i686-linux/usr/bin/autoconf --force
autoreconf: running: /home/gumstix/oe-core/build/out-glibc/sysroots/i686-linux/usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:34: installing './compile'
configure.ac:30: installing './missing'
src/Makefile.am: installing './depcomp'
autoreconf: running: gnu-configize
autoreconf: Leaving directory `.'
/home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/temp/run.do_configure.12034: 188: /home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/temp/run.do_configure.12034: oe_runconf: not found
WARNING: exit code 127 from a shell command.
ERROR: Function failed: do_configure (log file is located at /home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/temp/log.do_configure.12034)

I have in local.conf (cut):


(I have Ubuntu 14.04 on a 32-bit system, which I need to change to x86_64 sometime)

I’ve tried successively:

$ bitbake -c clean libdmx
$ bitbake angstrom-lxde-image

$ bitbake -c cleanstate libdmx
$ bitbake angstrom-lxde-image

$ bitbake -c cleanall libdmx
$ bitbake angstrom-lxde-image

Fails at the same spot, every time. Google search brings up nothing. I’m not sure why it can’t find oe_runconf, as it seems to be used fairly prolifically in recipe *.bb files. I’ve tried deleting the entire oe-core folder and rebuilding fresh.

It seems the libdmx_1.1.3.bb is in openembedded-core/meta/recipes-graphics, and has 2 deps: libxext and dmxproto.

Any ideas? Or am I stuck with V2.4?

This looks very strange.

/home/gumstix/oe-core/build/out-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/libdmx/1_1.1.3-r0/temp/run.do_configure.12034: oe_runconf: not found

oe_runconf is a function in the very shell script which complains that it cannot be found.
Can you look in that run.do_configure script with a text editor if you see something special?

Is it possible that your layers did not all get updated so that some recipes/files have ‘old’ or changed content?

i.e. what is the output of:
$ repo status
$ git log --oneline -1

P.S. Please note that the kernel version used for our i.MX 6 based modules in V2.5 is 3.14.28.

I looked in the run.do_configure.12034 and that is the only “oe_runconf” reference (inside an if -e statement), so I don’t see the function definition in the script. I compared this to a run.do_configure in liba52, and wala! oe_runconf IS defined here! Are these run.do_configure’s generated from a script somewhere? They seem to multiply with a number suffix everytime bitbake is run. I don’t understand the bitbake build process enough to know why.

I started a new build in another separate directory, fresh git, default bblayers.conf and MACHINE adjusted for apalis-imx6 local.conf, following http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/openembedded-(core)#V21_and_Later_Images exactly. Still fails. libdmx’s run.do_configure is still missing oe_runconf def! I don’t understand why this occurs.

I realize the “extra layers” (meta-fsl-arm, meta-fsl-arm-extra) are default.

I’m building on a Xeon W3550 with 4G ram, with gcc-4.8.4 installed. I bumped up to BB_NUMBER_THREADS=“8” because it was taking forever (6000 tasks). It didn’t change the result.

Also, “repo status” on old oe-core dir gave normal:
nothing to commit (working directory clean)

This is really strange.

do.run_configure is created by bitbake from the recipe and other meta data in the layers.
So it baffles me that the function oe_runconf is missing for libdmx and even more that it actually is not missing in other autotools based recipes.

  • So what versions of all the layers do you actually use? E.g as reported at the beginning of every bitbake run.
  • Do all of the xorg-lib recipes show this behaviour? (they share a common inc file). e.g. did ‘bitbake libxext’ succeed?

Sidenote: bitbake puts together the run.do_xxx scripts and postfixes them with the PID of the current process.

Strange is right.

Build Configuration:
BB_VERSION        = "1.26.0"
BUILD_SYS         = "i686-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS        = "arm-angstrom-linux-gnueabi"
MACHINE           = "apalis-imx6"
DISTRO            = "angstrom"
DISTRO_VERSION    = "v2015.06"
TUNE_FEATURES     = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU        = "vfp-neon"
meta-angstrom     = "(nobranch):4a04eeaf3cbe5d0006ea552e78c43aefb095c40b"
meta-toradex      = "(nobranch):eca5937408c75a997b160bd1b92e1496b07421cf"
meta-linaro-toolchain = "(nobranch):08a46787862966f2236c5a9b3eb4d4ec68263593"
meta-python       = "(nobranch):763de0599bd61eae1c122782b03e12b66319a2f1"
meta-lxde         = "(nobranch):dab628bb88504e72ef1ed2c47577c03934606ec4"
meta-browser      = "(nobranch):06aab8ea56aa130f26a3651fc3a370fba3d967f1"
meta-fsl-arm      = "(nobranch):c9f259a4bf8472dfa3ff75f1c3fcbe5e0ded7aaf"
meta-fsl-arm-extra = "(nobranch):41e79c6bd055f12b6252618c22c43a2fed5cfb49"
meta-fsl-demos    = "(nobranch):17f9da65efb5c65c1d44b5cc18584034b29a742b"
meta              = "(nobranch):f0873b83d693af4a103999160d67fcf25c7eedc1"

I looked at libxext and it has oe_runconf()… Where can I look for logging of the script generation scripts?

gumstix@linuxDev:~/oe-core/stuff/openembedded-core$ git log -1
commit f0873b83d693af4a103999160d67fcf25c7eedc1
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Tue Sep 29 14:59:41 2015 +0100

    build-appliance-image: Update to fido head revision
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Seems like it is up-to-date. I figured “repo sync” would update all subdirectory git repos, but looking at fido shows recent commits. I’m not very familiar with repo, or what underlying git repo is responsible for this funny error.

The layer versions are the ones for V2.5.
(The magic that tells repo what versions to checkout is in oe-core/.repo/manifest.xml so they may be more recent commits on a fido branch than what we used for V2.5 Beta3)

I’m not aware that bitbake writes debug logfiles. You can make it produce much more verbose output one of -D, -DD, -DDD. e.g. you could:

bitbake -c cleansstate libdmx
bitbake -c patch libdmx
bitbake -DDD -c configure libdmx 2>&1 | tee build.txt

I did install a Ubuntu 14.04 32 bit today, installed the prerequisites as outlined on the Toradex oe-core page and installed the V2.5 meta data.
The following did successfully build, no hick ups with configure:

MACHINE=apalis-imx6 bitbake libdmx