[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