Unix Makefile (Chris Lewis's Small C)

[Carl S. Gutekunst]

In article <1916 at brl-smoke.ARPA> Cornelia B. Murphy writes:
>We recently received the source code for Chris Lewis's version of Ron Cain's
>Small-C compiler.  We're running on System V and have all the proper
>modifications as Chris has instructed.  However, when running the
>makefile to compile the source, the following sequential makefile lines 
>generate the following error messages:
>
>          ranlib scclib.a
>Make:  Cannot load ranlib.  Stop.
>
>          ucb ranlib scclib.a
>Make:  Cannot load ucb.  Stop.

In article <4782 at sun.uucp> guy at sun.uucp (Guy Harris) writes:
>"ranlib" is done automatically by the System V "ar" command.
> [... explanatory comments about Pyramid systems deleted ...]
>In short, blow both the "ranlib" lines away; you don't need them.

Not quite.  Here's the section of Chris's makefile that's causing the problem:

	#Alternately, you may have to do an lorder
	$(LIB):	$(FE)
		-ranlib $(LIB)
		-ucb ranlib $(LIB)

Chris got lazy. This is a hazard when using a UNIX(R) port that mixes Berkeley
and AT&T, but usually less of a problem on dual-port operating systems like
Pyramid OSx, Apollo Domain/IX, and Ridge ROS. Dual-port systems keep all (or
most of) the utilities from both systems available in parallel directory
trees, but when you run in one "universe," a prefix command ('ucb' and 'att'
on the Pyramid) is required to reference commands in the other. 

Archive files need to be properly ordered for one-pass access by ld(1). In
System V.0, the correct way to do this to use the lorder(1) and tsort(1)
utilities to construct the argument list to ar: 

	ar cr archive `lorder *.o | tsort`

Starting with (I think) System V.1, ar(1) does the sort internally, so funny
arguments to ar(1) are unnecessary. Hence Guy's statement is true, but only
on more recent versions of System V.

Berkeley went a different route, as usual. :-) ranlib(1) is a standard 4.2bsd
utility that both sorts the archive, and prepends a table of contents. It
doesn't exist in any stock System V port.

Chris's machine is a Pyramid 90x running OSx 2.5, which supports System V.0
and 4.2bsd. So his AT&T ar(1) doesn't do the sort. But he should have used
ar `lorder|tsort`, not ranlib.

Chris's one-line comment implies that he knew he was doing something that was
non-portable, but for whatever reason he went ahead with it. Since he usually
does an outstanding job, I'm a bit surprised he made this blunder, but I'm not
going to flame him for it. :-)
--
Carl S. Gutekunst   {allegra,cmcl2,decwrl,hplabs,ut-sally,utzoo}!pyramid!csg
Pyramid Technology Corp, Mountain View, CA  +1 415 965 7200