On Friday 10 October 2008 12:05:55 Loïc Grenié wrote: > 2008/10/10 Bernhard Reutner-Fischer <[EMAIL PROTECTED]>: > > On Fri, Oct 10, 2008 at 05:24:55PM +0200, Loïc Grenié wrote: > >>2008/10/10 Bernhard Reutner-Fischer <[EMAIL PROTECTED]>: > >>> 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 _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
