[uClibc]Putting uclibc in a linux distribution?

[Rob Landley]

I have a small linux distribution that's just used in-house at my company 
right now, but which I plan to GPL soon.  It's called "firmware linux", and 
puts the whole OS into a single zisofs (compressed cd-rom) image that goes on 
the hard drive (in the "var" partition) and gets loopback mounted on bootup 
as the root partition.  Everything that needs to stay modifiable is a symlink 
into the "var" partition (generally /dev/hda1), and the "home" partition is 
another mount point for modificable stuff.  The advantage is that you can 
upgrade the whole OS by replacing a single file, hence the name "firmware 
linux".  This is a "build from source" system (no package management, for 
obvious reasons, but just twiddle the build scripts and source tarballs and 
rerun "build.sh" to get a fresh system, with firmware file and install cd, or 
you could chroot/boot straight into the destination directory and keep the 
root partition modifiable system if you want to debug stuff....)

Right now it's using glibc, which sucketh mightily.  (I could explain why at 
length, but will refrain.)  I'm looking into replacing it with uclibc, and 
was wondering what kind of land mines I'm likely to run into?

So far it doesn't have any desktop elements yet, just a modified linux from 
scratch base plus a couple dozen server and utility packages (apache, samba, 
bind, python, ssh, iptables, traceroute, db, gdb, hdparm, dhcpcd, dhcpd, ppp, 
rp-pppoe, lynx, bc/dc, readline, zlib, rsync, cdrecord (mkisofs), zisofs, 
gnupg, ntop and its prerequisites (libpng, gd, libpcab, gdbm), ntp, eject, a 
partridge in a pear tree, and some home-grown code I'm not too worried about 
being able to fix if it breaks.  Anything there already known not to work?

I can't find instructions on how a native uclibc system is supposed to be set 
up.  There's a cross-compiler wrapper, but that's not what I'm looking for.  
(I've already got a static build phase that uses whatever the host system's 
libc is to give me a static environment I can chroot into and rebuild 
everything, and I'm happy with that.  I want it to rebuild from itself, and 
from red hat/suse/debian/etc.)  So I want to have uclibc be the default libc 
for the new system, and build gcc so that it knows uclibc is the default 
glibc.  Anything in particular I should know before I wade in?

I'm shiping a version of this project that uses glibc (what works now) before 
messing with the switch, so it'll be a couple weeks (end of the month, 
probably) before I can devote serious time to this, but I thought I'd ask 
around a bit first...

I'm not exactly looking for a "stripped down to the bare metal embedded 
system".  The firmware image still has the man pages in it and everything.  I 
just don't like glibc (the FSF took over 800 lines of C to write "cat", but 
that's NOTHING compared to the bloat and obscurity in glibc) , and think that 
a simpler implementation that does the same thing is inherently better.  
(I'll be looking at busybox as well, eventually, although if it had a "build 
seperate little tiny executables" mode I'd be happier.  One nice thing about 
zisofs format: no 4k round-up on file size. :)

Rob