Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: libraries
Message-ID: <15080@mimsy.UUCP>
Date: 19 Dec 88 21:59:10 GMT
References: <14946@mimsy.UUCP> <1269@nusdhub.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 59

>In article <14946@mimsy.UUCP> I suggested, half kidding:
>>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?

In article <1269@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.)
writes:
>Wrong! cammel breath ;-)
>
>The *proper* use of object libraries is to *organize* your objects into
>a usefull search order.

You might try reading the article to which you are responding, and then
thinking about it.%  A Unix `.a' `library' file is simply a file containing
other files, plus (depending on your system) a symbol table (in the
`sub-file' __.SYMDEF).  Now then, what is a Unix directory?
-----
% Especially if it is one of my articles. :-)  I might also add a cheap
shot here about using `spell'...
-----

If your answer was `a file containing other files', congratulations.

Now, aside from the actual implementation, what is the difference between
a library file that contains other files and a library directory that
contains other files?

If your answer was `none', congratulations again.

>How many times would you have to scan the contents of /usr/lib/*.o to
>load one relatively complex c program (say vn).

Either one time, or (preferably) zero times.

>As modules called modules that the program itself didn't use, you introduce
>the probability that the directory would have to be searched multiple times.
>If you tried to aleviate that the files would have to be ordered by names
>that reflected dependancies instead of content.

This is all quite false.  Even without using a ranlib (symbol table
file) scheme, the directory need only be searched once, and every file
within it opened once to build the linker's symbol table; then, or
after reading the symdef file, those files that contained needed
routines would have to be opened once to read their contents.

>Then you would have all the extra system calls that would spring up
>to open, search, and close all those files.

The extra system calls argument is valid: if you needed N object
modules out of the `-lc' library, you would have to open N+1 files (1
for the symtab file) rather than 1 file.  It is, however, the very same
argument that `proves' that fork()+exec() is wrong.  I claim that the
open and close calls---there are no `search' calls, though there may be
a higher percentage of read()s, along with fewer or no lseek()s---
*should* not be so expensive.  I also find it very likely that those
who claim it is too expensive have not tested it.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris