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

[Vladimir N. Oleynik]

Manuel Novoa III wrote:

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

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


> floating point support in printf 

> locales
> wide character functions

YES! Eternal problem of latin-1-abc people!

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

+ all formats for printf(), users formats
+ nss
+ tzset
+ daemon
+ vdprintf
+ getopt_long
+ getlogin
+ *rand48
+ setbuf
+ and many.

I write the first time in this mailist, and is perfect in have become
puzzled, where have put fopen() ? :)
And after all of you will write it, whether will fail glibc?

I think, that there is more interesting problem - to write 
cross-utilites the library (not libc).
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.


--w
vodz