ok, what's the story on toolchains?

i'm trying to clarify what the options are for toolchains for the
BB, and there's a lot of info out there, and a lot of it's confusing.
i can see that some of the distro builds will generate a toolchain,
while there are various versions at codesourcery and, hey, it might
even be possible to create an appropriate toolchain using something
like crosstool or crosstool-ng, as long as you properly patch the
source first or something like that.

  so, skipping to the bottom of the page, is there a single toolchain
that is appropriate for the BB? that will correctly build all the
software bits and additional apps afterwards?

rday

I believe Angstrom is built bottom-to-top with OpenEmbedded. If you
start with an installation of bitbake and an x86 native compiler, plus
a git-ed copy of the bitbake recipes for OpenEmbedded, it will
download and compile all of the additional x86-native compilation
tools, x86->ARM cross-compilation tools, ARM OS and ARM application
sources, plus patches, and do all the patching and compilation for
you. It is a bit complex and time-consuming the first time, and I had
difficulty finding the ultimate result files, but after poking around
a while I was able to do what I needed to. It is both a bit scary and
quite amazing to watch the machinery go as it collects all the bits
and builds itself. Other than a few issues where I had broken/partial
downloads that I had to manually fix, it worked well. But I would not
recommend it for the novice developer or Linux novice.

As part of the build process for OE, the sources to the
CodeSourcery-patched cross-compilers seem to be downloaded and built,
although with arm-angstrom instead of the arm-none prefixes that the
CodeSourcery downloadable binaries use. In any case, you get a full
set of cross-compilation tools, and can build as much or as little of
the ARM-native app set as you want (like console-only, X11, X11 with
demo apps, etc.)

If you don't use OpenEmbedded, you can download and install the
CodeSourcery cross-compiler binaries, individual bits of the source to
the OS and apps, and then configure your build environment. I haven't
done that myself, but I suspect for simple apps it would be easier.
But if you want to build anything approaching a full image, I would
think OpenEmbedded is the route to take. There are certainly concerns,
like making sure you have a good stable base to start with, but it
looks like there is now a "stable" branch that hopefully lives up to
its name (but which I haven't tried).

Brett

Angstrom doesn't use CSL toolchains, they are just too buggy and broken.

regards,

Koen

Koen Kooi <koen@beagleboard.org> writes:

As I mentioned on another post, I built my toolchain using this handy
tutorial (GPP part for the normal ARM compilation)

http://www.pixhawk.ethz.ch/wiki/tutorials/omap/dsp_toolchain

hth

OK, thanks for the clarification. I thought I had seen some kind of
CSL patch applied during one of the builds this would have been a few
months ago), but I must have misread it.

Brett

I found what I was thinking of. One of the paths is:
tmp/work/armv7a-angstrom-linux-gnueabi/gcc-cross-kernel-4.2.1-4.2.1+csl-arm-2007q3-53-r4

I assumed the "csl" in that path referred to the CodeSourcery stuff
(although I'm not sure what I thought the "l" was for).

Brett

This is CodeSourcery stuff indeed. It was used for linux-omap older then
2.6.27 which was not booting when built with normal GCC. Newer kernels
works fine with normal GCC 4.3.x which Ångström uses.

And CSL compiler was used only for kernel. Rest was built with normal
GCC.

Regards,