[uClibc]Putting uclibc in a linux distribution?

Erik Andersen andersen at codepoet.org
Thu Sep 12 04:12:45 UTC 2002


On Wed Sep 11, 2002 at 01:26:43PM -0400, Rob Landley wrote:
> 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 

cool.

> 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?

Sounds like fun.  The only major malfunction you might expect is
that our i18n/i10n support is not yet finished...  That is
currently expected to be done by mid November.

> 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?

Nothing jumps out at me as a problem.  Except maybe the
partridge, and we do have bit of a pear tree shortage at the
moment.

> 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.  

right.   You probably want to build a native version of gcc.

> (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?

There are actually several projects of this sort just getting
started.  I've heard of a few totally native uClibc development
systems being built.  I've built most all of the pieces at one 
time or another, but I've not built a distro myself.  Perhaps I
should just spend the time to build a Debian base system linked
vs uClibc for people to work with.  I expect that would do
wonders for getting things accepted.

> 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...

Sure.  Makes sense.

> 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. :)

I've often thought about building such a thing into busybox.
It wouldn't be especially hard to do...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--



More information about the uClibc mailing list