Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!kai
From: kai@uicsrd.csrd.uiuc.edu
Newsgroups: comp.unix.wizards
Subject: Re: IEEE 1003.2 (was Re: fixing rm
Message-ID: <43200058@uicsrd.csrd.uiuc.edu>
Date: 20 Dec 88 06:21:00 GMT
References: <396@aber-cs.UUCP>
Lines: 28
Nf-ID: #R:aber-cs.UUCP:396:uicsrd.csrd.uiuc.edu:43200058:000:1359
Nf-From: uicsrd.csrd.uiuc.edu!kai    Dec 20 00:21:00 1988


> In article <14946@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> 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?

Object libraries serve other functions as well (for some people).

Unless stored in object libraries, routines that reference each other will
not have their external references resolved correctly unless the object files
are linked in the correct order.  Put them in an library that was processed
by ranlib (or newer versions of ar), and ld handles it okay.  Maybe this is a
problem with ld.

Recursive references between two or more objects?  No matter how you order
the objects, you can forget it without libraries.  Okay, maybe this is
another problem with "ld".

Large numbers of object files?  You've apparently never worked on a program
so huge that */*.o expands to overflow the shell's command line buffer, so
there is absolutely no way to link without storing them all in a library
first.

You have a number of objects and want to test a new version of a single
object?  Well, cc -o testpgm main.o mytest.o mylib/*.o won't work, because
you'll get the original mytest.o as well, causing link errors, however cc -o
testpgm main.o mytest.o -lmylib does work.

Patrick Wolfe  (pat@kai.com, kailand!pat)