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
b. I'm not depending on Joe's toolchain (which may be gone
tomorrow). I'm assuming gcc, binutils, etc. will be around
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
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
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!