[uClibc]Re: [uClinux-dev] Making a _real_ release of uClibc

D. Jeff Dionne jeff at arcturusnetworks.com
Sat Nov 24 02:31:25 UTC 2001


Erik Andersen <andersen at codepoet.org> said:

> On Sat Nov 24, 2001 at 12:15:25AM -0000, D. Jeff Dionne wrote:
> > 
> > Well, let's take a look at what this new math lib is first.  If it'sthe 
> > Sun libm, that's the one I initially rejected for uC-libc...
> 
> It is a sun libm derivitive (taken from MacOs X), with glibc
> headers pasted on.   I threw out the cephes based libm I had
> been using because it was 1) huge and 2) had serious endianness
> problems on ARM and 3) was slow.
> 
> By default with the new libm I only build the C89 stuff, which is
> about 24k.  C99 support adds another 35+k.
> 
> So what was your concern with the sun libm?  Are those concerns
> still applicable?

Portability, correctness (cephes is single bit accurate).  I went cephes
for those reasons, but also because it was single precision (actually
there are cephes for everything up to 144bit) and it's all portable.
It you can make it assume nothing about what's under (except that
there is standard interger stuff) so it was really good for soft float.

I used it with the m68k soft float from gcc (which had to be hacked to
be position independant) for the GNU toolchain on Palm, and
everything else since.

I did'nt like the Sun stuff at all last I looked, it was a real mess... I'll look
again, you generally make good decisions so perhaps it just needed
work.

> > All that having been said, I'd make another .9x release, look at these 
issues
> > and then call it 1.0 sometime RSN.
> 
> I know I am still not at all happy with regex (which is huge).
> I think most everything else is reasonably sane,

Yup.  I still like the one that was there before, the GNU regex is,
well GNU so it's a real kitchen sink.  I'm also still concerned about
malloc, but really I will admit that since the last time we had a
conversation about it, I've not looked.  The Doug Lea malloc seems
to be the one people are using, but it's big.  Last I looked the
glibc one seemed to be a derivative work.  I think that's likely
what you've (still) got in there, which is a good thing I think except
that I'd like to move it _right into the kernel_ to replace kmalloc
in uClinux.  That means that in user space we'll still be wanting
thin wrappers around mmap.

Cheers,
J.

BTW, we ran into some scary structure mismatches between the
kernel and the uClibc on MIPS big endin uClinux.  Do you have
confidence the structures are correctly translated if/when needed
since user programs are no longer dependant on kernel headers?
Check out 5 arg syscalls.

> 
>  -Erik
> 
> --
> Erik B. Andersen             http://codepoet-consulting.com/
> --This message was written using 73% post-consumer electrons--
> 



-- 
D. Jeff Dionne                                        Jeff at ArcturusNetworks.com







More information about the uClibc mailing list