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 47719901 for ; Sun, 30 Dec 2018 19:25:17 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7D979AF37B; Mon, 31 Dec 2018 05:25:16 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 51099AF364; Mon, 31 Dec 2018 05:25:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="SzP1Q7+D"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9943AAF364; Mon, 31 Dec 2018 05:24:58 +1000 (AEST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by minnie.tuhs.org (Postfix) with ESMTPS id D5710AF363 for ; Mon, 31 Dec 2018 05:24:57 +1000 (AEST) Received: by mail-lf1-f42.google.com with SMTP id p6so17438985lfc.1 for ; Sun, 30 Dec 2018 11:24:57 -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=hcuOesIT4pvZ/i89z3NfEj4bmoPY/ji53B8H0497NVw=; b=SzP1Q7+DUtrPUp8Hilc7pQ0ZUFzQqs8cqubuEvNoXxYkGaWN5w4NYVwIFQ5u7Fa5/C KnoD6vp2RTteYhIVM68VkEtJuVFHBLyZRIWTMwau3+JT/uIvbtolXD2H8iBHKYpQ2nji iqScHoBdMWWwIJRZ1g/H6tqpRk3JxapAy9iNbDU1jV7ONaIZGMn0JBWSOrA2eX+TZBpT hyNLdtpm+jpR42sJdQ4Fu6N0SrB2zIFGnJB3JVSMO9e5fHI5ePVAnypy58h2pzVLpVNi VLF8ftDt8dat/T2MstWHgYJE4ZvgcujxYupBAby90rKaeUosx9kxJUobdmv+Q9UDRFpr QbWw== 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=hcuOesIT4pvZ/i89z3NfEj4bmoPY/ji53B8H0497NVw=; b=irTXIxNZqmzs1FtXozrXwQyJULXQ75xZljV+3rzbLaaV+nXXxvm2RArRDFc38p/ZaA X9Zd6etFoihivJYOUp5Nt/YGKh+irTuX90pPM9rmhlyIHlCIFvmRT8rt8SfxtEVHMYD2 CcnXpwcIlkJttaAMlCJoxpAIZkkqEwrr9PVP5IIJfgPx9ZE4AV27r+g6kzC/Yf8fx0wq slx/MvvPlB47dYYllSPhlDs+R6oUVQb9g6GWEBAjBMf8vA57XfVOOsFjzhrKzJlDL4zi cPxw+SF2ljsLLYD5YwpWjm2/wQ/cfDoJLfrGv1caOAbLzqbROR9x2VwsF64v4OPZ0yE8 bkhA== X-Gm-Message-State: AA+aEWbQy6jsgLMkfpXfM1wVe0+tA2u9KR2AHZxd8pEMOypM0eFBmw5Y JTerfp7nUETCXWoDDMvolpdPV8qqEhEHRFPwIUtG4Q== X-Google-Smtp-Source: AFSGD/WRX5fcQC1Lofv5wDS1t8DSFSadGfVod3W6Fw1fRg3WjMzMUIUMAff929RshChU30cxY/s+65TFvOrviNQMjgk= X-Received: by 2002:a19:5f1e:: with SMTP id t30mr16847281lfb.76.1546197896206; Sun, 30 Dec 2018 11:24:56 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a2e:3a11:0:0:0:0:0 with HTTP; Sun, 30 Dec 2018 11:24:55 -0800 (PST) In-Reply-To: <1546196832.22954.for-standards-violators@oclsc.org> References: <1546196832.22954.for-standards-violators@oclsc.org> From: Paul Winalski Date: Sun, 30 Dec 2018 14:24:55 -0500 Message-ID: To: Norman Wilson 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@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 12/30/18, Norman Wilson wrote: > > Ld could all along have just made two passes through the > library, one to assemble the same list ranlib did in advance, > a second to load the files. (Or perhaps a first pass to > load what it knows it needs and assemble the list, and a > second only if necessary.) That would avoid the O(N**2) situation I described in a reply to this thread. > Presumably it didn't both to > make ld simpler and because disk I/O was much slower back > then (especially on a heavily-loaded time-sharing system, > something far less common today). I suspect it would work > fine just to do it that way today. Probably not. For some reason linkers have always been notoriously slow when compared to other parts of the compilation toolchain. I suspect it's because of all the I/O involved. > 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. > Were I to wave flags over the matter I'd > rather push to ditch ar entirely save for compatibility > with the past, move to using tar rather than ar for object > libraries, and let ld do two passes when necessary rather > than requiring that libraries be specially prepared. As > I say, I think modern systems are fast enough that that > would work fine. The tar file format isn't as compact as ar's, since it operates on fixed-size blocks. Nowadays that wouldn't be a problem, but it certainly was when disks were small, given that object modules very often would be significantly smaller than a ranlib block. Making two passes over the entire library might be OK if the file system caches file contents, but it would still require at least one complete scan of the library, whereas if you have an index of global symbols, you just have to process that index (and, of course, the modules you finally decide to load). As I said earlier, linkers are slow enough as is--we don't need anything to make them less efficient. -Paul W.