[RFC] libm replacement for Busybox

[Rob Landley]

On Friday 10 October 2008 12:05:55 Loïc Grenié wrote:
> 2008/10/10 Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>:
> > On Fri, Oct 10, 2008 at 05:24:55PM +0200, Loïc Grenié wrote:
> >>2008/10/10 Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>:
> >>> On Fri, Oct 10, 2008 at 04:21:51PM +0200, Loïc Grenié wrote:
> >>>>     I've noticed that busybox uses few functions from libm.
> >>>
> >>> Actually, you can turn off ASH_MATH_SUPPORT_64 FEATURE_AWK_MATH and
> >>> you don't need libm at all.
> >>
> >>    dc uses pow. You are probably right that the other ones are not
> >>  needed in "constrained" platforms (initrd or embedded).
> >
> > yes, and dc is probably not in your initramfs either. And if you need dc
> > in you system (be it the initramfs or a normal system), then your system
> > is most likely so big that you don't worry about libm anyway.
>
>    dc is definitely in my initramfs. Not so much for the "pow" function but
>   for the basic four operations. I should probably use $(( )), right ? As
> for size, adding dc is 2035 bytes on x86_32 while libm is 141KB, not
> exactly in the same league !

Is it?  On bloated old 64 bit x86-64 uClibc I get:

-rw-r--r-- 1 landley landley 21416 2008-10-11 13:21 libm-0.9.29.so

Size optimizations for glibc are silly; you're already wasting a megabyte off 
the top (dynamically or statically linked).

In theory you can statically link against just libm.a and dynamically link the 
rest.  That might be worth looking at as a makefile tweak, although 
statically linking just that library and dynamically linking the rest starts 
raising "what exactly are you trying to do" questions.

But reimplementing chunks of libc in busybox _badly_ doesn't strike me as much 
of a plus no matter what the context...

Rob