[uClibc]Re: [BusyBox] here's a working multicall for e2fsprogs-1.18 _with_ uClibc support for i386

Manuel Novoa III mnovoa3 at bellsouth.net
Sat Jan 20 15:22:01 UTC 2001


Vladimir,

> > The shared bins generated for uClibc are slightly larger than those
> > generated linking with glibc; I guess that's what you're noticing.
> > One of the items on my personal list is to find out why... and fix it.
> 
> Hmm, You have understood what the reason?

I haven't had a chance to look at it yet.  I hope to have some time today.
One probable reason is that uClibc was written as a static library.  Hence,
the code is partitioned so that unneeded functions wouldn't get linked.  This
made it necessary for some internal variables and functions to be declared
extern rather than static.  This is one of the things I will check out.

> > My primary focus has become uClibc, and I don't really intend to 
> > pursue working on "e2fsbox".  I threw it together yesterday mainly 
> > as an excersise.
> 
> I not absolutely understand a principle of your demonstrating. 

There were several reasons:

1) There are undoubtedly people who monitor the busybox list because they
maintain small distributions or root/boot disks.  Even as posted, "e2fsbox"
gives these people an option they didn't have before.  Note that the use of
uClibc was not required... perhaps I wasn't clear about that.  You could use
glibc as well.

2) This may not translate, but perhaps you know the expression "priming the
pump".  I posted it as a starting point for anyone who might be looking for a
useful project to work on.

3) I thought it was important to show that uClibc could be used _right now_ to
build a significant _unpatched_ package besides busybox; especially now that
we have a shared verison of the library.  

> On idea e2fs-progs demand from libc only low level input-output.
> I was possible shall guess, what you have corrected? llseek? ;)

I've only been working with uClibc for a couple of months.  My initial
experiments with e2fsprogs started at that time.  Here are some of the problems
I recall encountering.

1) I needed some way to "persuade" the configure script to use uClibc.  Since
The gcc-uClibc-* wrapper program started as a quick hack to do just that.
It has grown into something far more useful than I could have imagined.

2) I needed to patch about 23 files to get around some uClibc vs. kernel header
file conflicts.  Almost all of those have been fixed now.  The remaining ones
required the -D__GLIBC__=2 compiler option, and those should be fixed within a
week.  I have several options about how to fix this, and need to get some
feedback from Erik and others on this list about which route we want to take.

3) I needed modify about 7 uses of floating point output by printf.  At the
time, uClibc printf would abort when processing floating point conversions.

4) uClibc didn't support "long long"s in printf.

5) uClibc didn't have fork or sbrk on i386.

6) uClibc stdio initialization was broken.

> + all formats for printf(), users formats

Right now, the only thing that should be missing from printf is floating point,
although there is a small bug with 0-prefixed octal that I need to fix.  Both
are on my near-term project list.  I recently did a major rewrite of the printf
code to fix a number of bugs and add some missing features.  I even managed to
reduce the object size by about 20% in the process.  ;-)  If you know of any
features that are missing or of any instances where it misbehaves though,
please let me know.

> + getopt_long

getopt_long was added more than two weeks ago.  See unistd/gnu_getopt.c.

> + setbuf

setbuf is defined in include/stdio.h as a macro.  It was actually on my list of
things to clean up.

> + and many.

Well, it _is_ a work in progress.  ;-)

> I write the first time in this mailist, and is perfect in have become
> puzzled, where have put fopen() ? :)

fopen is defined as a macro in include stdio.h.  Another candidate for the
continuing stdio cleanup.  ;-)  One of the things on my personal todo list is
to work on ANSI/ISO compatibility.  fopen should really be a function.

> And after all of you will write it, whether will fail glibc?

I don't understand your question.  I certainly don't expect glibc to fail. 
uClibc is targeted to small-memory uses and make size-vs-speed tradeoffs with
that in mind.  Both libraries are useful.

> I think, that there is more interesting problem - to write 
> cross-utilites the library (not libc).

We all have our interests.  I personally am enjoying working on uClibc.

> Example. Now there was a problem of check of the code on overflow.
> Practically in each utility we see such code in many places:
> strncpy(dst, src, size_dst); dst[size_dst-1]=0;
> In too time in many places it is visible necessary absence of such code.

Are you referring to uClibc or to busybox?  Or maybe something else?
If you know of any such bugs in uClibc, please let me know and I'll fix them.

Manuel





More information about the uClibc mailing list