IEEE 1003.2

Root Boy Jim rbj at nav.icst.nbs.gov
Wed Jan 4 17:18:49 AEST 1989


? From: Chris Torek <chris at mimsy.uucp>

? For that matter, why do we need object archives in the first place?
? They are just a hack to save space (and perhaps, but not necessarily,
? time).  How about /lib/libc/*.o?

Which is what `-lc' would `mean'. How about /lib/c/*.o?

? (About 1/2 :-) ---the file system is *supposed* to be clean enough and
? fast enough to support this sort of thing; why *are* we working against
? it?)

Yeah, except that the directorys aren't sorted or hashed so you can't
use them very well as a database :-)

(yes, I know how to sort directorys)

? From: Eduardo Krell <ekrell at hector.uucp>

? inodes were a scarce resource back then ...

? We had an implementation of archives as plain directories (with the proper
? changes to ar, ld, etc), and it worked just fine.

Exactly! And `ranlib dir' just creates `dir/__.SYMDEF'!

? Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

? From: Gordon Burditt <gordon at sneaky.tandy.com>

? Lots of the object files in libraries are tiny.  A considerable number of
? them just load a couple of registers and execute some kind of trapping
? instruction.  These are likely to be smaller than the amount of disk space
? used by an inode plus a directory entry.  

? Take, for example, the libc.a on my system (Tandy 6000).
? There are 202 files in libc.a, and it takes up 211 512-byte blocks, not
? counting indirect blocks.  The average size of an object file, including
? the ar header, is 534 bytes.  

So glom some of them together! Chances are, if you're gonna use `open',
you're gonna use `close', and most likely `read', `write', and `lseek' too.
And even if you don't, the minimal extra space isn't gonna kill you.

And with shared librarys, it doen't even matter, as you get the whole
thing anyway (at least I think so :-).

	(Root Boy) Jim Cottrell	(301) 975-5688
	<rbj at nav.icst.nbs.gov> or <rbj at icst-cmr.arpa>
	Crackers and Worms -- Breakfast of Champions!



More information about the Comp.unix.wizards mailing list