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

Erik Andersen andersen at lineo.com
Fri Jan 19 20:56:52 UTC 2001


On Fri Jan 19, 2001 at 01:31:06PM -0600, Manuel Novoa III wrote:
> 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. 

Yes.  Some time we need to make a list of "Official uClibc Policy Guidelines". 
If I had to start writing such a beast right now, I would begin with the
following:
    
    Guideline #1:
	When presented with a choice between smaller size and faster speed, 
	always choose smaller size.
    
    Guideline #2:
	When presented with a choice between standards compliance (i.e.
	Posix/IEEE Std 1003.1), and size, always choose standards compliance.

    Guideline #3:
	When choosing between compatibility with GNU libc, and smaller size,
	selecting compatibility with GNU libc is only acceptable if the GNU
	extensions meet the following criteria:
	    1) they cannot be easily implemented another way
	    2) the standard uClibc feature set must not depend on these extensions
	    3) the extensions must make sense for embedded systems

I think we some further discussion and thought, these guidelines should be
included into the source tree to help people understand the underlying
philosophy.  Clearly, we don't want to just add stuff till this becomes as
encumbered as glibc.  Selecting what does and does not go in is of supreme
importance.

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

:-) 

I'm working on a few things yet, but networking support is going to be rapidly
moving to the top of my TODO list.  Right now, there are still a few things I
needs to fix first.

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

Agreed.  Though this fits into the need for better configurability, since we
want this, but we want it configurable.  I'm half tempted to grab the Linux
2.2.x kernel menuconfig system and use that....

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

Cool!  As do I.  Numerical methods is one of my first loves in the computing
arena.  Despite appearances to the contrary, I'm actually a mechanical engineer
with a minor in math and much of my masters work was in numerical methods.
I've got some extensive numerical methods and signal processing background.
That part is gonna be fun.  :-)

> 	locales
> 	wide character functions
> 	internationalization support
> 	network support is incomplete
> 	[th]search functions
> 	threads
> 	support for lots of archs that glibc supports

I think we need to turn this list into an official README file in the source tree. 

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--





More information about the uClibc mailing list