[busybox] RFC: disable libm?

[Michael Tokarev <mjt@tls.msk.ru>]

In current busybox config, two config options enabled
that depends on libm (math functions): these are math
support for awk and dc.  For dc it's just pow and exp
functions, for awk it's a whole lot of functions -
usual sin cos tan atan log sqrt pow exp, maybe some
others.

Neither of the two are enabled for udeb config, so
d-i is not affected.

I've built both variants for both configs, and here's
the refults (i386 build):

   text    data     bss     dec     hex filename
 420316    1787    8984  431087   693ef bb-1.18-deb-libm
 419792    1751    8984  430527   691bf bb-1.18-deb-nolibm
1275926    2461   18646 1297033  13ca89 bb-1.18-static-libm
1262664    2457   18646 1283767  1396b7 bb-1.18-static-nolibm

The size difference is actually very small, which
surprizes me alot - I didn't expect such a small
change for statici build, which should pull quite
alot of code.  Maybe it was this way in old good
times, but now each of the above functions is
done using a single instruction to the co-processor
(as we called it before - now it's integral part
of the CPU, at least on x86 arch).

So after looking at all this I'm not sure I want
to remove libm support, except of this:

   text    data     bss     dec     hex filename
 144706     348      64  145118   236de /lib/libm.so.6

this is 144 extra Kb which needs to be placed into
initramfs if busybox (regular deb config) is to be
used there.  Compared with combined libc and busybox
size:

   text    data     bss     dec     hex filename
1298787   10112   12288 1321187  1428e3 /lib/libc.so.6

this is less than 10%, but that's not all the tools
in initramfs, we've more there.  So I'd say libm can
be kept, not a big deal, probably not worth a discussion
even.. ;)

But I'm not sure for other arches, where the difference
may be much more significant.

Thanks!

/mjt