Unix Makefile (Chris Lewis's Small C)

[guy at sun.UUCP]

> 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.

I.e., it's not true on System V.-1?  System V.1 was the first System V
release, so I'm not sure what less-recent versions you're referring to.
BTW, S5's "ar" doesn't sort the archive, it just prepends a table of contents
which is similar to the "ranlib" one.

> Berkeley went a different route, as usual. :-)

Wrongo.  "ranlib" comes from an AT&T UNIX - V7.  (Note the use of "an"
before "AT&T UNIX" - there is no unique referent for the term "AT&T UNIX".)

> ranlib(1) is a standard 4.2bsd utility that both sorts the archive, and
> prepends a table of contents.

No, it doesn't sort the archive.  It just prepends a table of contents which
is similar to the one prepended by S5's "ar".

> It doesn't exist in any stock System V port.

It could, though; it would just have to be a shell script which did

	for i in "$@"
	do
		ar ts $i >/dev/null
	done

which would, like the V7/4BSD "ar", regenerate the table of contents for
each archive given as an argument.

Doing so in a system intending to support both environments would mean a
"Makefile" from a 4.2BSD environment would be more likely to work in either
environment.

> Chris's machine is a Pyramid 90x running OSx 2.5, which supports System V.0
> and 4.2bsd.

What is "System V.0"?  There was a release called just System V, followed by
a release called System V Release 2.  That first release was either System V
Release 0 (release names have to be comprehensible to non-C programmers, so
they tend not to be 0-based, making this unlikely) or System V Release 1.
In either case, *both* release most definitely *did* support the
table-of-contents generation.  The S5R1 version had a portable archive
format which was completely different from the 4BSD version; they came to
their senses in S5R2 and adopted the 4BSD version with a minor change
(archive member names are padded with '/', not ' ').

> So his AT&T ar(1) doesn't do the sort. But he should have used
> ar `lorder|tsort`, not ranlib.

The former will work in either environment, although if "ld" is the 4BSD
version it will give a warning if the table of contents is absent.

It's unlikely that the target system uses two different object file formats
in the different environments, as that is likely to lead to endless
confusion (and higher costs to support the OS, as you have to support two
assemblers *and* possibly two compilers, two linkers, two archivers, two
"nm"s, two "strip"s, etc.).

If the target system uses the 4BSD object file format, either 1) the "ar" in
the S5 environment can have "ranlib" built into it (be careful, though -
"ranlib" adds a table of contents regardless of whether the archive
contained any object files or not - "ar ?s" shouldn't do so unless the
archive contains object files), so that if the command updates the archive
or if the "s" key is specified, the table of contents (member name
"__.SYMDEF") will be updated, or 2) the "ranlib" program should be available
in the S5 environment.  (This requires S5 Makefiles to be updated; however,
if you're using the 4BSD object file tools, the ones which use COFF-specific
features will have to be updated anyway.)

If the target system uses the COFF, there should only be one "ar", which
should be the S5 one, in which case there's no need for "ranlib", but it
should be supplied as described above so that 4BSD Makefiles will work with
relatively little change (although, again, if they rely on features specific
to pre-COFF systems, they may have to change).
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)