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

[Erik Andersen]

On Sat Jan 20, 2001 at 10:31:32AM -0600, Manuel Novoa III wrote:
> Erik,
> 
> Welcome back.  ;-)

Thanks!

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

Mostly platform support issues at the moment.

> 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

I am looing into something related, but not identical.  There are some size
increases vs an older version of uClibc as well.  I am investigating these.


> 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

interesting line of research I had not considered.  Looks 
potentially promissing.

> 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

good, good.

> 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

such as the macro vs funtion thing.  Excellent.

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

Excellent idea.

 -Erik

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