Path: utzoo!attcan!uunet!lll-winken!ames!nrl-cmf!ukma!gatech!bloom-beacon!bu-cs!mirror!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: libraries
Message-ID: <7@minya.UUCP>
Date: 8 Jan 89 05:44:59 GMT
References: <15080@mimsy.UUCP> <1278@nusdhub.UUCP> <15126@mimsy.UUCP> <445@thirdi.UUCP>
Organization: (none)
Lines: 37

In article <445@thirdi.UUCP>, peter@thirdi.UUCP (Peter Rowell) writes:
> 
> What if a "library" was simply an editable file that contained the
> names (possibly including *'s and such) of interesting .o files.
> Additionally, there could be an optional SYMDEF file that had the
> already-munched global symbol info in it.
> 
> The benefits include:
> 
[ benefits deleted ]
> 
> This seems to handle what I was getting from Chris Torek's original
> posting (quick, cheap libraries), and seems to handle the objections
> of some of the other people.  It should be absolutely trivial to add
> the first part (the library file itself), and pretty straightforward
> to do the SYMDEF stuff.
> 
> Comments?

Yeah.  I've worked off and on with Intermetrics' set of compilers (the
one designed for doing cross-compiling and downloading for standalone,
embedded microprocessors).  They do exactly this sort of thing.  It
works just fine.  The performance of the linker seems to easily match
the Unix linkers, though the Intermetrics linker actually does quite
a bit more.  They also have "time wasting" features like object files
that are actually printable ASCII.  They still run quite fast.

As for the cost of all the extra directory searching:  Do you think 
that archives don't contain a directory, or that searching through 
them is free?  Why should one expect that the linker's search through 
an (unsorted) archive directory will be any faster than the kernel's?

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]