[uClibc]Why is uClibc so much smaller than glibc?

Manuel Novoa III mnovoa3 at bellsouth.net
Fri Jan 19 19:31:06 UTC 2001


Hello,

On Thu, 18 Jan 2001, you wrote:
> Why is uClibc so much smaller than glibc?  Is is just through paying 
> attention to the size, fewer features, size-vs-speed tradeoffs, or ?

I know that I've paid attention to size in just about all the code I've
contributed.  When I've been confronted with size-vs-speed tradeoffs, I've
generally chosen to minimize size provided I'm roughly the same order of
magnitude speedwise. 

There are fewer features, but in some cases these are selectable at build time
(although a better mechanism for that needs to be implemented).  Some features
just haven't been implemented yet.  I know I've used uClibc to successfully
build busybox, ext2fsprogs, fdisk (with some tweaking as I recall), the reiserfs
utilities, and ash-0.2.  As yet, the network support is incomplete but I
noticed that Erik had checked some stuff in a few days ago.  And of course, we
can now compile uClibc as a shared lib.  Thanks again Erik!

A good example of a size-vs-speed tradeoff is the stdlib/qsort.c implementation.
It uses a shell sort and a char-by-char exchange and the object text size on
i386 is only 183 bytes.

> In other words, what would I be giving up by using uClibc?

An incomplete list of things I can think of that are currently missing from uClibc:

 	floating point support in printf (well, not missing but _real_ limited)
 		(this is on my list for the near future)
	floating porint _period_ -- no math.h to speak of
		(I'll probably work on this at some point, as I have a numerical
		 analysis background)
	locales
	wide character functions
	internationalization support
	network support is incomplete
	[th]search functions
	threads
	support for lots of archs that glibc supports

Hope that helps.

Manuel





More information about the uClibc mailing list