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

Manuel Novoa III mnovoa3 at bellsouth.net
Sat Jan 20 16:31:32 UTC 2001


Erik,

Welcome back.  ;-)

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

Adding a guidelines file to the tree is a good idea.  

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

What are you working on right now besides the networking support?  Don't want
to duplicate effort.

My current list of things to look at:
--------------------------------------------------------
uClibc configuration method

find out why some shared-libc execs are a little larger for uClibc than
	glibc in the e2fsprogs package

seperate builds for static and shared lib versions?
	in the shared case, it may be better to collect some internal
	functions and variable and make them static to reduce number
	of exported symbols -- use the preprocessor to make declare
	these as extern or static depending on desired output

howto document for adding archs - things to watch be aware of
	needed symbols in crt0 for correct initialization (stdio, etc)
	how to add unified syscall support for other archs than i386

fix the uClibc vs linux header problem - perhaps have a seperate
	"include0" (better name needed) dir placed ahead of "include"
	in the search list by gcc-uClibc and wrap the problem linux/*.h
	files there to fix the __GLIBC__ macro-defined problem?

check if NR_FILE and NR_OPEN needed in sys/param.h?

setbuffer - make internal with weak symbol? and make setbuf a function
fopen - make it a function
printf:
	fix 0-prefix octal bug
	floating point support
	stack-allocate fake-file for the sprintf functions
stdio in general : misc other cleanups

sysconf.c - right now size of sysconf.o is almost 800 bytes for 132 cases,
	but only returns 29 distict values ; maybe auto-generating the
	include and the function to cut the size? (use tables)

sys_errlist.c - right now size of text seg is 3748 bytes ; maybe compress
	messages for static-lib case with "weak" strerr overriden if
	sys_errlist is used?  (strsignal as well)

locale support ? - at least for "C" locale
onexit - add back a glibc-compatible version
floating point functions

eliminate problem static variables as initial prep to a thread-safe version
----------------------------------------------------------

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

I can start collecting options in a central file and documenting them in
another, a-la the kernel.  Just pick names and locations and I can do the
printf and strto* functions as a start.

Also, I really think the configuration should be exported as a header file to
the include directory, perhaps as uClibc-config.h or some such.  That would
allow uClibc-aware apps to test for the presence of features.

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

Absolutely! ;-)  Most of what I worked on was related to reliable numerical
computing methods; nonlinear systems solving using interval methods in
particular.

Manuel





More information about the uClibc mailing list