What is your strategy on cross compilation toolchains? Here we explore a
few options:

• DIY - requires you to manually start each step, unless you're comfortable enough to script the process. As each step takes ages, this can be a tedious job. However, it gives you full control and insight into each step.
• crosstool [http://www.kegel.com/crosstool/] - a scripted version of DIY + patches. Used to be my preferred tool, but hasn't been updated since 2006. Limited to glibc.
• crosstool-NG [http://ymorin.is-a-geek.org/projects/crosstool] - a rewrite of crosstool. Provides a menuconfig configuration interface, which makes it quite easy to use. You can also pass configurations around. Supports glibc, but also uclibc and eglibc.
• buildroot [http://buildroot.uclibc.org/] - builds a uclibc-based gcc in the process of building an entire system. The toolchain can be ripped out (you can also force buildroot to use an external toolchain - thus avoiding building the same toolchain over and over again). As the focus is on the entire system, this approach provides little insight of the toolchain, but in my experience, the outcome usually works well.
• scratchbox [http://www.scratchbox.org/] - provides uclibc or glibc based toolchains. Approaches cross compilation is a new way - providing an environment where the actual cross part of the compilation is abstracted away. Also provides an emulated target environment, so you can run your ARM binaries on your standard PC from within the scratchbox environment.

The available options are ordered in some sort of control freak factor order, where DIY provides loads of control over every tiny aspect, while scratchbox just makes things work.

Myself? Last time around I used ct-ng, but I've used them all (and will not DIY again unless forced ;) ).