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 4c6fa9d6 for ; Sun, 30 Dec 2018 19:02:21 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id DC8D4AF376; Mon, 31 Dec 2018 05:02:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 224E6AF363; Mon, 31 Dec 2018 05:02:08 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="oLd0jCAW"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9656594140; Mon, 31 Dec 2018 05:02:06 +1000 (AEST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by minnie.tuhs.org (Postfix) with ESMTPS id E074F94140 for ; Mon, 31 Dec 2018 05:02:05 +1000 (AEST) Received: by mail-lj1-f174.google.com with SMTP id u89-v6so22464379lje.1 for ; Sun, 30 Dec 2018 11:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sgv4+a0CS+abXKCKLaeHfBRMspRzgIrxfvgs2A2yZNc=; b=oLd0jCAWem2hFttQIT7IGUiQtHSFZJmTCc7TYNKPch98CZE3CdC+9VbF6LSOX30knS PZ5YwIPcCdH5qZSvvycJNr0I7e38wvXE19NT7T5GciRdFIz5ap0Uk8X4lPpeI2FMUOAK VU3S3Jik40o3qbCKsr+sUjErPr0glTgtzi2V2McJ447k1mhh6z0fxtiT3RPnqL0wEOxn MFFUjoF+pwotEbFE+A1k3JYW6eQPYDyr1oCTWhdZ7wtjhqJ/J4ZG2wMMpwgFabQS1yis CBlV/Z5oY3nKuP0/0fEY8eHFM4O9Ql2ZWHrOJlc4nGVZuVLHDj846+MJcjIQ1eOzX6yP TxLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sgv4+a0CS+abXKCKLaeHfBRMspRzgIrxfvgs2A2yZNc=; b=e5R3p/q0BGsaA+V9KS4eLRBJQQ0eZhYDOfalioXhqhvqysH9STsgQ4g9wBSoYO/LfW ZPOpZcColkZmITDpeT13aEZ3mQEUSpNdq75eNCJ0ouVo/gQUIbLPNC8otaJCKUX2Z6Xx 33sweNZbJBTcbk4Ye1rNB5/ohVU1J6jFMGpUtyM4mvxUana7KkjNVmM+JIFVpYDupQCA ZCR2wJC5i5Ot3m1Olpjzcfw8PNvdwEFxQv4/BNnZyuh6aar7Bane5X0O19dt4DFuf76f Pq6/rAY2273mAUmQEtay312XVtik5diWQXa5KKQTnvQ9DVmSKRv2DdYp1pH6r+NJvBTT RPew== X-Gm-Message-State: AJcUukfEMDr+8/6GHzJVCAR+PzP7eiSH8jV2N7hFbNgqQkRQYPfpgs7P SmQKaagjPk6ad61WrUYNcyy6pno+hQVq6eaLnXDEVQ== X-Google-Smtp-Source: AFSGD/VKh3xhu+Gulo+rNYaI7lAyBk3TOyzhHl9Ux0YjWfoYSk8PZzdO6sDJLOuGR2ycI/BYXdxUdnhB4mxhPW2Wb9Y= X-Received: by 2002:a2e:890b:: with SMTP id d11-v6mr18614749lji.113.1546196524295; Sun, 30 Dec 2018 11:02:04 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a2e:3a11:0:0:0:0:0 with HTTP; Sun, 30 Dec 2018 11:02:03 -0800 (PST) In-Reply-To: <128301d4a070$4794ea70$d6bebf50$@ronnatalie.com> References: <20181229010900.19F6218C074@mercury.lcs.mit.edu> <128301d4a070$4794ea70$d6bebf50$@ronnatalie.com> From: Paul Winalski Date: Sun, 30 Dec 2018 14:02:03 -0500 Message-ID: To: ron@ronnatalie.com 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: , Cc: tuhs@minnie.tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 12/30/18, ron@ronnatalie.com wrote: > Yes, it pretty much has to be this way as it is a single pass process and > the ar format is simple. Early ld only made a single pass over each library on the command line? Interesting. Most linkers (all modern ones?) make repeated passes over a library until a pass doesn't resolve any symbols; only then does the linker go on to the next library or object module on the command line. A single pass link makes some sense, though, on a resource-constrained system--it's easier to implement, and a multi-pass link has O(N**2) worst-case behavior. ranlib greatly speeds up the link process, but early implementations of ranlib had a problem (I would call it a bug): they indexed common symbols as well as globals. Common symbol semantics require that if an undefined external resolves against a common symbol, that in itself is not enough to cause the object module to be loaded. So even with ranlib it's necessary for the linker to process the symbol table of each module that gets a hit when the ranlib index is processed, and to ignore instances where the resolution is against a common symbol. ld had a bug in this area that caused common symbol sizes to be maximized improperly, and one of the stdio modules had a dependency on this bug. Later versions of UNIX didn't have this bug; I don't know whether it was ld or the stdio module that was fixed (I suspect the latter). -Paul W.