From owner-freebsd-hackers  Fri Sep  8 21:39:08 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id VAA02699
          for hackers-outgoing; Fri, 8 Sep 1995 21:39:08 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id VAA02689
          for <freebsd-hackers@freefall.freebsd.org>; Fri, 8 Sep 1995 21:38:55 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA12459; Sat, 9 Sep 1995 14:34:28 +1000
Date: Sat, 9 Sep 1995 14:34:28 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199509090434.OAA12459@godzilla.zeta.org.au>
To: freebsd-hackers@freefall.freebsd.org, rmallory@wiley.csusb.edu
Subject: Re: install/ranlib of libraries
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>...anyways, I noticed that the install directive in the makefile
>in the library section first install(1)'s the library, then ranlib's
>it. SunOS likes to ranlib it in the working directory, then install
>it, then ranlib it again. This makes good sense, since I got a 
>"ranlib --missing symbol table" on my libc.a when it installed it.

Libraries are ranlib'ed when they are built.  Ranlib'ing them before
installing them would gratuitously clobber the internal and external
library timestamps and make all binaries out of date.  Ranlib'ing them
after installing them has the same bug.  Ranlib'ing them after
installing them is currently necessary because install clobbers the
external timestamp and ranlib must be run to fix the internal timestamp.
Perhaps other versions of ranlib are smarter about the timestamps.
E.g., it would be useful to have an option to set the external timestamp
to the internal one.  Our `install' will soon be smarter about
timestamps.

Bruce