[ On Sunday, March 18, 2001 at 20:35:05 (+0100), wojtek@wojtek.from.pl wrote: ]
> Subject: Re: why /bin and /sbin static
>
> because of no need of ld-so processing.
> it could be faster in case of slow-CPU and lot of RAM/fast disk like in
> m68k.

That's more or less exactly my point!

If your 486 system had similarly scaled I/O throughput then I'll bet it
wouldn't suffer so much from the static binaries in /bin and /sbin.

> there is not a problem if there is 2 times on disk, but if it's on memory
> two times. reducing working code set will pay dividents on any hardware,
> and on alpha 1000Mhz with 1GB RAM TOO! because more will fit in CPU cache.
> 
> trying to make code smaller is always GOOD. talking about that my computer
> is not the last rocket with 1GB RAM is a poor excuse. just compare
> 16kB /bin/ls filesize with >200kB of static linked one!
> 
> this is over 10 times larger!!!!

Indeed.

But do not *ever* get fooled into comparing file sizes.  They
are almost meaninless for unix binaries and they can be very very
misleading (eg. in the case of unstripped binaries, etc.).  Always
always always use "size" when talking about the non-disk resources used
by binaries.

So, for /bin/ls it's actually worse (over 24 times larger!):

	$ size -t obj.i386/*.o 
	text    data    bss     dec     hex     filename
	749     0       0       749     2ed     obj.i386/cmp.o
	3922    24      12      3958    f76     obj.i386/ls.o
	16      0       0       16      10      obj.i386/main.o
	3598    4       8       3610    e1a     obj.i386/print.o
	1563    0       128     1691    69b     obj.i386/stat_flags.o
	234     0       0       234     ea      obj.i386/util.o
	10082   28      148     10258   2812    (TOTALS)
	
	$ size /bin/ls
	text    data    bss     dec     hex     filename
	244963  2632    18844   266439  410c7   /bin/ls

> in the other hand i can't understand why over 200kB of code is needed for
> ls from C library?!

In this case I don't yet know....  it's rather dismal, especially given
the frequency with which people use /bin/ls!
 
> is C library so weak organized or i missed something?

/bin/sh is similarly horrid:

	$ size -t obj.i386/*.o | tail -1
	73474   2399    52      75925   12895   (TOTALS)

	$ size /bin/sh
	text    data    bss     dec     hex     filename
	395707  9112    19964   424783  67b4f   /bin/sh

(but then /bin/sh pulls in libedit and libtermcap, which is potentially
about 82kb of extra text)

Of course libc is relatively huge (and much larger than what it
contributes to either /bin/ls or /bin/sh, etc.):

	$ size /usr/lib/libc.so
	text    data    bss     dec     hex     filename
	514301  11748   44480   570529  8b4a1   /usr/lib/libc.so

and as you suspect there could well be some dependency in it that causes
much more to be pulled in when linked statically than is really
necessary....


It's not always so bad.  The One True Awk manages to go static in a
half-decent size and still not pull that much from libc (especially
given its functionality and capabilities):

	$ size -t obj.i386/*.o
	text    data    bss     dec     hex     filename
	7009    41248   0       48257   bc81    obj.i386/awkgram.o
	8276    28      20      8324    2084    obj.i386/b.o
	6411    576     0       6987    1b4b    obj.i386/lex.o
	7775    220     0       7995    1f3b    obj.i386/lib.o
	1788    24      0       1812    714     obj.i386/main.o
	1269    0       0       1269    4f5     obj.i386/parse.o
	604     752     100     1456    5b0     obj.i386/proctab.o
	19615   592     0       20207   4eef    obj.i386/run.o
	4414    0       0       4414    113e    obj.i386/tran.o
	57161   43440   120     100721  18971   (TOTALS)
	
	$ size /bin/awk        
	text    data    bss     dec     hex     filename
	122549  44160   3880    170589  29a5d   /bin/awk

so that's what, only about 64kb of code from libc....

It's still a lot, but given the feature-rich malloc and stdio I guess
it's not too terribly much....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>