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

[Vladimir N. Oleynik]

Manuel Novoa III wrote:

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

Just in case - I do not insist. Simply interest.

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

Yes here that all is easier. For last month it was offered 3
realizations e2fs-utils. Two mine. The third - yours.
Old problem...

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

Hmm, please: %r, vasprintf, 
also see /usr/include/printf.h (glibc2.X) ... (not in man)

For realization of the last it is necessary to rewrite all from zero.
Later appearance of such interface has resulted to that in 10 % of
utilities is necessary to refuse from library printf and 
to write itself. An example - pppd (utils.c file)

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

There can be a translation was not understandable. I use the machine 
translator. :) 
I am afraid, that after you add a set of possibilities glibc in uclibc,
all advantages will disappear. 
How many I not examine glibc code, I and have not seen where there 
it is possible to remove size, all is very compact, size gives quantity.

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

No, it concerns universal problems. :) It Is concrete to uclibc -
implementation, for example, ctype: first can give significant size at
usage, second it is possible to tell, that it and 
is not present at all. :)


--w
vodz