Bitbake recipes

[Jason Winnebeck]

I'm trying to learn a bit more about Bitbake recipes and how they work
in the hopes to make modifications/patches to existing recipes easier
and also I'm thinking this sounds like a good tool to build my own
libraries and 3rd party libraries/programs I might want on the
beaglebone.

I had a very hard time finding documentation. Google was not useful to
me. Actually the most useful link I found was from this list to the
OpenEmbedded User Manual at http://docs.openembedded.org/usermanual/html/index.html,
which somehow never showed up on my Google searches. I kept on finding
really old/obsolete pages or pages without hardly any info. I wrote a
blog post about my research this weekend with more details here
http://gillius.org/blog/2012/02/understanding-angstrom-bitbake-recipes.html
in the hopes of helping others trying to figure this out as well.

If anyone knows of a better/more recent manual and/or tutorials let me
know.

[Brian Hutchinson]

http://docs.openembedded.org/usermanual/usermanual.html
http://bitbake.berlios.de/manual/

And check out Yocto projects documentation. It uses OE Core just like
Angstrom and so you can glean information there too.
http://www.yoctoproject.org/documentation

Of course for all things BeagleBoard & embedded Linux ... the elinux
site is your friend.
http://elinux.org/BeagleBoard

That ought to be enough to keep you busy for a while :)

Regards,

Brian

[jon]

Jason,

Were you able to find a simple answer? I've been trying to create a simple recipe: an SDK with libusb and libudev. I've spent countless hours trying to accomplish this simple task, slogging through obscure bitbake error messages. One thing I discovered (the hard way) after upgrading my setup scripts to the latest version was that all the recipes directories moved and I didn't know it. I had been simply been working out of the wrong directory -- total waste of time!

Right now I'm getting some weird dependency error: "dependency glibc resulted in conflicting PREFERRED_PROVIDER entries found." At this point, I'm not sure what to do, except, perhaps, get away from bitbake/OE. Not quite ready to give up yet though....

Jon

[Jason Winnebeck]

I was able to compile a "hello world" and also compile a kernel module. That was all I wanted to do for now so I haven't moved past that. My next step was to figure out how to properly set up a layer so that bitbake can scan the recipe. I ran my recipe using the -b flag and pointing it to the bb file. The interesting part is that I HAD to give it an absolute path (starting with /), if I didn't, it looked for a package named as the path (for example it interpreted blah/recipe.bb as a recipe name rather than a path to the recipe file, so I had to use /home/me/blah/recipe.bb for example).

I imagine that building something more would just involve using the proper -l flags, because bitbake sets up the compiler with sysroot, so basically it means it uses the include and lib directories of the cross-compiled environment instead of your machine, but I haven't actually tried this yet.

The fact that you are depending on glibc is odd if you are building for the bone, because eglibc is used. Maybe the message is because bitbake is getting confused by multiple libcs. But really that's just a shot in the air since I've only done two recipes so far.

If you can get your program to be something that is just compiled by a typical ./configure; make; make install, then I would expect that you should be able to look at existing recipes for simple programs and how they are compiled and just duplicate that. The recipe doesn't actually do the guts of the build process, it's just supposed to "wrap around" your existing build process.

Jason

[jon]

Sounds good, sir.

Regarding glibc dependency -- I am hoping I can remove the libraries that are in conflict, but first, I am building another toolchain to be sure my environment is at least set up properly.  Things got weird for me after running "git pull" as suggested in the OE documentation.  But I'll look into replacing glibc with elibc... thanks for the advice.

I also built my own kernel as the default uses System V IPC, and I needed POSIX message queues. I think it's unfortunate to have to rebuild the kernel to do this. Alas...

When I started using bitbake/OE way back when, I was successful in making a recipe for building my particular app with it. But the build process with OE/bitbake added so much time to the development cycle, I decided to just build the cross compiler, and work outside of the OE environment. I might go back to doing it that way once I have an SDK that I can use.

Good times.