From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 01c12a53 for ; Mon, 31 Dec 2018 03:23:01 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2CC41AF378; Mon, 31 Dec 2018 13:23:00 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 9480DAF363; Mon, 31 Dec 2018 13:22:43 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="PdrzXA/+"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A27BEAF363; Mon, 31 Dec 2018 13:22:42 +1000 (AEST) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by minnie.tuhs.org (Postfix) with ESMTPS id EBB4D94140 for ; Mon, 31 Dec 2018 13:22:41 +1000 (AEST) Received: by mail-ua1-f46.google.com with SMTP id t8so8378488uap.0 for ; Sun, 30 Dec 2018 19:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=U3Gq/8UGh7/dfYx6fv6Ad5jeTuN3wLewmFD6ngsu/Qk=; b=PdrzXA/+TbwIa0qnIwOuyOOsQM5U3k7+VF6tUoI8phYiZF2xgka+h+JwjV1FBum836 K0FxjSvkgzvTnDlqN/CJ5Vnuh3ZGg6kGzrezGj+KOaECaehOKkCuY4KYLDUhCBZLnoyD dNqIZ0xykXFtvD3aeFUEF7stU/S3wLFFWasPP/0e5RY93mB76GdmCe8/giJLUJ+qD1Ik 0pevf/FXG7sLDiKy78jhpoa8QGlGros6/tJCrtBtNlh8LbdJ1PtlVU6t3l4fD+bRhlLa oemnmYTSX2/cY4gYJH0z43BvNBzU+wrttcY2zr7jWss92RmM1F25YGfg6+ZmNmMXwqpi ItPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U3Gq/8UGh7/dfYx6fv6Ad5jeTuN3wLewmFD6ngsu/Qk=; b=rt5+TAZev9nW5Abu3yTrQe8J4+P64odwfwazKlnJMyJQRdPhDz4QtkjHfxZzqgNPPD wkxCUGn/2ye5GbskBncdnQzREu/QNErep9MiteaoThxo5Gq2LW/nkJGgQNuBh9jD49QH z1+T30dQ8w//8Eu/kW+aPRz5vkBB1GPRrqpcurOCVyQUdKoedbQ2PuMlw9Ssd9SoMp7l +fLEwZgqu8KuCdImLYtwxeth5KxI4EWk36oxWs0/KRVY3et3CFakO7Yj3Y2Dp+ulbtWS LCOU7r9ml3b+7Szzyu6Ao7PXgrWkPMLTQyn6iLRDrDIQIOE0RT4pKMwxMcUSDkSAvCy3 kWzw== X-Gm-Message-State: AJcUukfxH78Q5VOKxiFjM0vHALZ17gewrySktbBEXg90VqhtkAEwXfht 45kOXz/sv3tZsuOzT6wuxxherW6xViEz9t3D1ss6 X-Google-Smtp-Source: ALg8bN5gkMFg2d9QYRLaeouRBeq3a15k21SD1xGy/9zYbe2HgPeTskjEEw0bQGSL8OHKe+gKLFB+cSmBObuiT1GMq6U= X-Received: by 2002:ab0:590a:: with SMTP id n10mr13487943uad.137.1546226560792; Sun, 30 Dec 2018 19:22:40 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab0:2f7:0:0:0:0:0 with HTTP; Sun, 30 Dec 2018 19:22:40 -0800 (PST) From: Rudi Blom Date: Mon, 31 Dec 2018 10:22:40 +0700 Message-ID: To: tuhs@tuhs.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" >Date: Sun, 30 Dec 2018 14:24:55 -0500 >From: Paul Winalski >To: Norman Wilson >Cc: tuhs@tuhs.org >Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable? >Message-ID: > BriRGtxBY0J10Q@mail.gmail.com> >Content-Type: text/plain; charset="UTF-8" > >On 12/30/18, Norman Wilson wrote: > >> >> >> 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