Date: Sun, 30 Dec 2018 14:24:55 -0500
From: Paul Winalski <paul.winalski(a)gmail.com>
To: Norman Wilson <norman(a)oclsc.org>
Cc: tuhs(a)tuhs.org
Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
Message-ID:
<CABH=_VTqZzNXPNecFCVZeqfMTnoJiWHbXZz->BriRGtxBY0J10Q(a)mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On 12/30/18, Norman Wilson <norman(a)oclsc.org> wrote:
<snip>
Nowadays ranlib is no longer a separate program: ar
recognizes object files and maintains an index if any are
present. I never especially liked that; ar is in.
principle a general tool so why should it have a special
case for one type of file? But in practice I don't know
anyone who uses ar for anything except libraries any more
(everyone uses tar for the general case, since .it does a.
better job).
As you say, nobody these days uses ar for anything except object
module libraries. And just about anything you do that modifies an ar
library will require re-running ranlib afterwards. So as a
convenience and as a way to avoid cockpit errors, it makes sense to
merge the ranlib function into ar. MacOS still uses an independent
ranlib, and it's a pain in the butt to have to remember to run ranlib
after each time you modify an archive.
Maybe not on some of the older, more (resource) restricted systems,
but now normally wouldn't modifying an archive be part of
definitions/rules in a makefile and as such wouldn't the makefile
include using ranlib if an archive was modified ?
uncle rubl