Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: openembedded-devel@lists.openembedded.org
Subject: Re: Debugging OpenEmbedded Builds
Date: Fri, 07 Oct 2011 10:42:43 +0100	[thread overview]
Message-ID: <4E8EC993.9030105@dynamicdevices.co.uk> (raw)
In-Reply-To: <4E81B106.8040801@tu-braunschweig.de>

Hi Christian,

What I often do to check out the recipe building is something like this...

bitbake -D -f -c clean foobarrecipe

The -D gives you lots of debugging output so you can see things happening

The -f forces bitbake to do what you say

(otherwise it's likely to check its internal state for a recipe, decide 
the recipe has already been built, and ignore you. You can often tell if 
you've been ignored as it'll say XXX tasks, of which XXX didn't need to 
be executed, where XXX is the same number meaning nothing happened)

The -c specifies a command. The clean command wipes out the working 
directory in your tree. The working directory will depend on what you're 
building but will probably be somewhere in 
./openembedded/build/tmp_XXX/work/. You can use find or similar on the 
name of your recipe to figure out where it is.

So clean wipes things out, then you can try

bitbake -D -c compile foobarrecipe

Note that we're not forcing things here, and we already have that recipe 
in a "clean" state which means bitbake
will go through the intermediary stages to get a compilation done, 
unpacking, patching and so forth.

After that's finished you can go to the working directory for the recipe 
and see what happened - you should see
output files and so forth, and you can look in the temp folder in there 
to see the logs and scripts that are used.

Also, you probably want to make sure RM_WORK is commented out of your 
configuration file (local.conf I think)
as otherwise bitbake will clean up the working directories after itself. 
I still think the compile command I suggest
will work ok but if you do a full build of a recipe then at the end the 
work files will be cleaned. Note that removing
RM_WORK will likely make your build tree MUCH bigger!

There are better ways I'm sure, such as using devshell, but this is the 
mechanism that works for me.

Cheers,

Alex Lennon

Dynamic Devices Ltd
http://www.dynamicdevices.co.uk

On 27/09/2011 12:18, Christian Keck wrote:
> How can debug an OpenEmbedded build? I have made some changes to a 
> board file, but it seems that my changes have no effect. Is there a 
> opportunity to look into source code just before they are compiled?
>
> Thanks, Christian
>



      parent reply	other threads:[~2011-10-07  9:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-27 11:18 Debugging OpenEmbedded Builds Christian Keck
2011-09-27 15:04 ` Holger Freyther
2011-10-07  9:42 ` Alex J Lennon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E8EC993.9030105@dynamicdevices.co.uk \
    --to=ajlennon@dynamicdevices.co.uk \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox