IEEE 1003.2

[Gordon Burditt]

>For that matter why not just combine tar and ar and add a flag to tar
>to include an archive symbol table (and have tar recognize this has
>been done on input.) It seems the two functions of these utilities
>barely needs to be distinguished. A simple shell script could replace

This is likely to cost quite a bit in disk space to store libraries, and
would probably at least double storage requirements.  

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.  

If you used tar, the same library would take up 404 512-byte blocks,
minimum, and the average size of an object file, including the tar
header, would be at least 1024 bytes.  (None of the object files are
empty, so each would take up 1 block for the data plus one for the
tar header.)  Actually the total size would be closer to 530 blocks.

If you used the (Sys V) file system with a 512-byte blocksize, the files 
would take up 328 512-byte blocks for data, plus 26 blocks for inodes, 
plus 7 blocks for directory entries.  (calculated using the SysV file 
system, but the BSD file system would use about the same for directory 
entries), for a total of 361 512-byte blocks.

If you used the (Sys V) file system with a 1024-byte blocksize, the
files would take up about 492 512-byte blocks, plus 26 blocks for 
inodes and 8 blocks for directory entries, for a total of 526 512-byte 
blocks.

Summary:
Method		Size
ar		211
Filesys 512	361
Filesys 1024	526
tar		530

Disk space is NOT the only important feature about an object library
format.  It's not totally unimportant, either.

Disk I/O for typical link:
	These are all fairly close to the same, as long as a convention
exists to find the index easily.  Tar formats would probably have to
adopt a method of reading the last block and scanning backwards to find
the index.

Ease of updating:
	Filesystem libraries are a big win.  Tar loses, since it adds 
replacement object files on the end without removing the old one, thus, 
the library is perpetually growing.  The index-builder also has to be 
careful not to include references to outdated modules.  
	
Portability:
	Filesystems are not very portable by themselves, but there
are plenty of tools to package bunches of files (like tar) for
transportation.  Tar and ar formats are reasonably portable
(I did not say mailable or postable).  Of course, object files
themselves have limited portability.

					Gordon L. Burditt
					...!texbell!sneaky!gordon