Re: [Gumstix-users] BitBake vs Cross Compilation...why bother?

[Trevor W. <two...@gm...>]

OpenEmbedded and Bitbake are doing lots and lots of "voodoo" in the
background to build for you not just an executable, but the entire
system including: cross development tools, bootloader,
cross-libraries, applications, root filesystem, etc...

If you're sitting down at an Intel-based Linux distribution and have
the "regular" gcc compiler collection installed, as sophisticated as
it is, all it is able to produce are applications which can be run on
intel-based instruction sets. You can pass it flags to, say, target a
486 instead of a Pentium-II. You can pass it all the flags you want
and it won't produce code for your ARM processor. You need a compiler
which runs on your intel-based machine but which produces code for
another architecture entirely (in other words, a cross-compiler). But
the compiler is just but one piece of the entire compiler collection,
other parts include the assembler, the linker, the preprocessor, and
so on. For completion sake you can also build, on one machine (A), a
compiler which generates code for another architecture (B), but which
runs on yet another architecture (C)! This is called Canadian-cross
compiler.

But creating a cross compiler (or a Canadian-cross compiler) is not
just a simple matter of saying: ./configure --target=arm. There are
many variations of ARM, there are different thread models to choose
from, there are different languages you might optionally want to
support, there are different "at exit()" strategies to choose from,
dynamic loaders, multiple language libraries to choose from.... and on
and on it goes. For example, just focusing on C language libraries,
you have uClibc, glibc, eglibc, newlib, and others. Crafting the
correct ./configure line to target different targets is an art in
itself. But it gets worse, not only is that difficult enough, but in
many cases various versions of the various tools have known compile
problems. So if you want to create a compiler to target ARM based on
gcc-a.b.c you'll need to apply these bunch of patches before you can
start building your cross compiler! Those patches just sort of float
around and don't seem to ever get applied to gcc for reasons I don't
quite understand.

Each piece of this puzzle (assembler, linker, compiler, language
library, ...) are independent projects. There are all these things to
choose from, and for each piece, numerous versions of each piece to
choose from! As you can probably guess nobody has the time to test
every version of every piece with every version of every other piece
to see if they work together, or even compile together.

One of the first things OE+BB does is create this cross toolchain for you.

You just type one command and it picks from sets of tools known to
work and compile together, applies any required patches to get it all
working, makes all the decisions for you, and you end up with a
working compiler.

... and so far I've only talked about the first thing OE+BB does for
you :-D See Dave's email for some of the other stuff it does :-) Using
this compiler it then creates a filesystem, a bootloader,
applications, GUI stuff, packages, etc.

The advantage of OE+BB for an embedded developer is: OE+BB isn't just
for gumstix, the people behind these tools are trying to add support
for all target processors, for all development boards, for all
languages, for all filesystems. It becomes the stored repository for
all the knowledge about which combinations work, what patches are
required, and so forth. So learning this one tool allows you to
develop for a range of targets without having to learn a new tool
(which was common in the past).

OE+BB isn't perfect, it is but one such project trying to make
embedded cross-development easier.