Next Previous Contents

4. Debugging

This chapter describes some debugging examples.

If e.g. a package is not buildable, a build command does not finish, because a package is not found, etc., this chapter may give some hints, how to get it running, or where to get the necessary info from to ask the irc channle or mail the problem efficient.

We start desribing some bitbake functions, which may help to find buggy packages / configurations. After that, we describe some example problems and the way to get the problems (temporary) fixed.

4.1 Bitbake features for debugging

Debugging output (-D)

One option to get more information on the build process is to use additionally the -D option. This option may occur multiple times and thus increases the DebugLevel.

A small extract of bitbake -D -D -D nano is shown below.

        
DEBUG: CONF reading /home/sc/scdev/oe/org.openembedded.dev/conf/bitbake.conf
DEBUG: CONF file 'conf/site.conf' not found
DEBUG: CONF file 'conf/auto.conf' not found
DEBUG: CONF including /data/scdev2/build-x86/conf/local.conf
DEBUG: CONF file 'conf/build/i686-linux.conf' not found
DEBUG: CONF file 'conf/target/INVALID-linux.conf' not found
DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/machine/dsa-x86.conf
DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/distro/generic.conf
DEBUG: CONF including /home/sc/scdev/oe/org.openembedded.dev/conf/documentation.conf
DEBUG: collecting .bb files
NOTE: Using cache in '/data/scdev2/build-x86/tmp/cache'
DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/aalib/aalib_1.4rc5.bb
Parsing .bb files, please wait...DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/abiword/abiword_2.0.14.bb
DEBUG: bbmake: parsing /home/sc/scdev/oe/org.openembedded.dev/packages/abiword/abiword_2.2.7.bb
...
DEBUG: BB /home/sc/scdev/oe/org.openembedded.dev/packages/busybox/slingbox_1.00.bb: handle(data)
DEBUG: BB :0: inheriting classes/base.bbclass
DEBUG: BB classes/base.bbclass: handle(data, include)
DEBUG: BB :0: inheriting classes/package_tar.bbclass
DEBUG: BB classes/package_tar.bbclass: handle(data, include)
...
       

You can see, that you are provided with lots of information, if you want.

Show environment -e

The option -e shows the environment variables set during a bitbake run.

This parameter may be used with just the bitbake command ( without a package ). In this case the environment variables build by just the diffenrent config files is show. You can easily check, whether your configuration is OK, after e.g. changing or creating a local configuration.

Called with a package name, the complete packages dependency is checked. The list of variables provided is the one used if the package is build.

See the partial output produced by bitbake -e nano below.

        
# CPPFLAGS=${TARGET_CPPFLAGS}
export CPPFLAGS="-I/data/scdev2/build-x86/tmp/staging/i686-linux/include"

# OLDPWD=/home/sc/scdev/oe
# DEBIAN_MIRROR=ftp://ftp.debian.org/debian/pool
DEBIAN_MIRROR="ftp://ftp.debian.org/debian/pool"

# LICENSE=unknown
LICENSE="unknown"

# HANDHELDS_CVS=cvs://anoncvs:anoncvs@cvs.handhelds.org/cvs
HANDHELDS_CVS="cvs://anoncvs:anoncvs@cvs.handhelds.org/cvs"
...
        

You can see always a line strting with "#", which shows the variable definition before expansion.

Note, that this list maybe very long and thus should either be redirected to a file or directly grep'd.

Show package versions -s

This command parses the complete package repository(s) and provides the last available and if configured the preferred package version (see gcc example below).

        
...
galculator                                 1.2.3-r7                     
gammu                                     1.02.0-r0                     
gawk                                       3.1.4-r2                     
gawk-native                                3.1.4-r2                     
gcalctool                                 5.5.21-r0                     
gcc                                        4.0.0-r1             3.4.4-r2
gcc-cross                                  4.0.0-r1                     
gcc-cross-initial                          3.4.4-r1                     
gcc-cross-kernel-3.3.3                     3.3.3-r2                     
gcc-cross-kernel-3.3.4                     3.3.4-r2                     
gcc-cross-kernel-3.4.4                     3.4.4-r1                     
gcc-cross-sdk                              3.3.4-r2                     
...
        

Dry run -n

The dry run can be used to check, whether all dependencies are fullfilled. Also versioning, etc. can be checked.

        
[OE-X86]sc@schomep4:/data/scdev2/build-x86$ bitbake -n nano
NOTE: Using cache in '/data/scdev2/build-x86/tmp/cache'
NOTE: Parsing finished. 2602 cached, 0 parsed, 96 skipped, 0 masked.
NOTE: build 200509270855: started

OE Build Configuration:
TARGET_ARCH   = "i686"
TARGET_OS     = "linux"
MACHINE       = "dsa-x86"
DISTRO        = "generic"
TARGET_FPU    = ""

NOTE: package ncurses-native-5.4: started
NOTE: package ncurses-native-5.4: completed
NOTE: package ncurses-5.4: started
NOTE: package ncurses-5.4: completed
NOTE: package nano-1.3.5: started
NOTE: package nano-1.3.5: completed
NOTE: build 200509270855: completed
Build statistics:
  Attempted builds: 3
[OE-X86]sc@schomep4:/data/scdev2/build-x86$           
        

4.2 Speed up package build (in case of errors)

If you run into problems (errors during build process), you do not want to parse all repository files again and again. In this case you can build a package directly.

A bitbake -b whereYourOEPackageDirIsbitbake/nano/nano_1.3.5.bb / will just build nano. All depends have already to be fullfilled for that (which is normally true, if your build stopped at nano).


Next Previous Contents