I'm trying to create an embedded linux (Linux From Scratch I suppose) with only the following "packages":

1. Linux kernel (pretty stripped down)
2. Busybox (statically linked with uClibc)
3. Dropbear (statically linked with uClibc)

Note: I got this idea from the Free Electrons "Embedded Linux From Scratch in 40 minutes!" article (http://free-electrons.com/articles). Great article!

The machine I have here is a Pentium 700 MHz running Debian Etch, which I hope to use for building if I don't end up in the loony bin first. Note that Debian Etch uses glibc, which immediately rules out the possibility of using this machine as the native build host, right? (I'm assuming there's no way to link with uClibc without doing something tricky to the glibc gcc?)

Here are the approaches I've seen for doing this sort of thing on the net:
1. Build a "cross compiler" (i386 uClibc) and invoke it via environment
variables (such as CC) to make Busybox and Dropbear.
Problems with this approach:
It seems hard to find a complete, standard list of environment
variables to "cross-library" compile in this way. I've seen
CC, CXX, AR, RANLIB, LD, etc. But how do I know I'm not missing
CXY? This scares me, as it seems like the host can "leak" into the
target if I forget an environment variable (not real easy to tell if
I missed one).

2. Create a temporary build environment with manually
compiled/installed development tools (gcc, binutils, make, uClibc,
etc), chroot to it, and configure & build the packages within the
temporary build root. I like this approach much better, as:
a. Host leakage should be prevented, since the configuration
scripts will abort if they don't see something they need in my
build environment.
b. I'm not depending on Joe's toolchain (which may be gone
tomorrow). I'm assuming gcc, binutils, etc. will be around
forever.
Problems with this approach:
If I'm trying to make and install gcc into /hostroot as an i386 uClibc
"cross compiler", the only way the configure script knows how to do
it is to pre-pend the weird target arch name, etc to the executables
to give me things like "bin/i386-pc-linux-uclibc-gcc". I assume that
after chrooting to this build environment, no configure script in
its right mind will recognize that as the compiler (or will they?)

3. Use Joe's tool chain to do everything for me
I realize that this whole thing may be that I'm too much of a control
freak. However (here come the complaints):
a. Joe may decide to become a fruit picker and stop working on
the tool. In which case I will be in trouble when I want to
upgrade in the future (need to change my approach).
b. Toolchains like to download the "latest and greatest" packages
It makes me nervous if running the tool today gives me a different
result than running it the exact same way tomorrow. (Need
"capturability".)
c. I can't hack my configure scripts to take out the "-g" compile
flag (I still don't know how that made it into the default
settings)
d. I don't understand everything it's doing!


So what is the industry standard way to cross compile? Many people have posted their opinion, or "what works" for a particular package, but I'm really looking for the best solution overall, which will lend itself to the least future rework, and a stable OS. Does anyone know? I sure haven't been able to find a solid answer anywhere. Thanks for reading my rant!

Well, you *could* just go to the LFS home page then click on the link to the CLFS project. They have a lot of patches, scripts, etc to build the toolchain (you can even use uclibc). After installation, 'dropbear' is one of the patched packaged bits of software you can compile.

Why use static links with libc? If you boot from an initramfs image then static linking really has no value.

If you're not happy with the versions of packages in CLFS you can substitute your own - as long as you don't mind figuring out what needs to be done and how to patch the sources so things will compile.

Just one suggestion with CLFS - put everything into scripts as you go along; you're bound to make a few mistakes and you wouldn't want to spend a few days typing all over again. Writing scripts as you go also allows you to wipe the entire build directory and attempt to rebuild all using your scripts (and discovering things you left out etc). After a week or so of playing around like this you should be able to just invoke one top-level script and your entire system and software will be built and packaged for deployment in about 35m (well, that depends a bit on your computer of course).

You can probably use that box as a native development box, just use the --nostdinc and --nostdlib options in gcc and the add the appropriate -I -L -l to use the uclibc stuff instead (including crt0 or crtbegin/crtend or whatever uclibc uses to do pre-main initialization and post cleanup).