From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 7fd739c9 for ; Thu, 19 Jul 2018 15:29:27 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 0766C9EB72; Fri, 20 Jul 2018 01:29:27 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id CC0C29E982; Fri, 20 Jul 2018 01:29:15 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=GmnAMrFN; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id AF2339E982; Fri, 20 Jul 2018 01:29:13 +1000 (AEST) Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by minnie.tuhs.org (Postfix) with ESMTPS id E3B009E3BA for ; Fri, 20 Jul 2018 01:29:12 +1000 (AEST) Received: by mail-lj1-f196.google.com with SMTP id p10-v6so8140338ljg.2 for ; Thu, 19 Jul 2018 08:29:12 -0700 (PDT) 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=E6Tq5O6UCpBMZDuAxxNa5c3SJWd/mKxM2fogqWgzo9Y=; b=GmnAMrFNvBg9gowWZ/5RYxbZEwdLhxjiwF1Bb83cyJJ/60Uz9jxO4vR8oitYWdQ+yB SSlmysn5vzamUsR1e0pf+mNsCGEgMcbubFyPoMZRpJR+RyxJg+sg5Us1e9WezPLBhXij jV3vf8xRs+VUluqm5A2YrtiCp0AdHSJdGfaf3YNSsP1HQhDGDlg8Kq5u49Il4Rqlqpfq RARNAoIWeeqRDOa/TKuVScs+4ac34nRS7+hNRZsygN3eM5ha/EAyzh72JK+qhxzA5vj6 MhS8uYKEnu1l2KLIvbVF12KWYcP3/U2joKT/zjM0IanCkD75ukhgLgp8uU2b564vUeBX D4ug== 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=E6Tq5O6UCpBMZDuAxxNa5c3SJWd/mKxM2fogqWgzo9Y=; b=jEgUe+xk0kGOeZwblfUmjcTj0fXneeRv/2Bvk03hIbqG2dFnLCMyhi2iURbsqq/1to UrAjX0Bh1F91dbGu1jXsqGPXkuTGPbPk/qiQ93YDdRf8ItkUZIpOWgG5eefqJHXEd1rM yWClE+qvPWucbvm4VpVSuh3ITThFAwB+t8Yz1yh5GkaXldt1vGCkpOLmjHwWgcTsJ2WK AHsVBUntKfHnF65SJ7HIcIp2lMb64kEeYUGGH2i1+7ufl8bXbJSGFzDfrMvu7bkJYrqZ Zm9Qb5Z+ufXREy5980/4c2+V/PboTiN7PbFrpuouHY80LpRy/t2XBIKxLC74r34nh6ua f8LA== X-Gm-Message-State: AOUpUlGqR9qCdbeyGLhnrnT9LTgU6XQRoRwXrPQtbL+1/a+Q5p+t+y/5 4xy4zyRSHAEUV5LFySmI1Jh/s6fZyZf3cRNfdkk= X-Google-Smtp-Source: AAOMgpepupj1PgOI0A7mWFrkept17eabhPuCLENdbhWEFCEXwwV8pEgW+5bMlJ6mavvCJrcOCpcneN83B0Te2I1098o= X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr8681503ljk.116.1532014151281; Thu, 19 Jul 2018 08:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:3c01:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 08:29:10 -0700 (PDT) In-Reply-To: <20180719045909.GD54853@eureka.lemis.com> References: <201807171320.w6HDKNTR023268@freefriends.org> <201807181739.w6IHdUZW004045@freefriends.org> <20180719045909.GD54853@eureka.lemis.com> From: Paul Winalski Date: Thu, 19 Jul 2018 11:29:10 -0400 Message-ID: To: "Greg 'groggy' Lehey" Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 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 Wednesday, 18 July 2018 at 11:39:30 -0600, arnold@skeeve.com wrote: > > Archive files (static libraries) are alive and well and work just fine, > on Linux and every other *nix that I know about. The format is even > used on Windows for static libraries and for whatever you call them when > linking dynamic libraries (they provide the symbols, but not the dll). The symbol index for archives of object (.o) files was initially optional and created by a separate program called ranlib. At some point ranlib seems to have been integrated into ar. When did this happen? The version of ranlib from the mid-1980s had an implementation that was a bit too simple-minded. It indexed all symbols with N_EXT set and a non-zero n_value field. This means that Fortran common blocks and C uninitialized file-scope variables ended up in the ranlib index of the archive, which is wrong--such symbols should not trigger an object file to be loaded. ranlib should have filtered out symbols that have N_UNDF set as well as N_EXT. ld had a faulty work-around for this problem. When a symbol in a ranlib index triggered the loading of a module, and ld found that the symbol was in fact a common symbol, ld said "oops" and unloaded the module. But by this time ld had already maximized the sizes of all common symbols, and that didn't get backed out. The result is that common symbols were allocated space in .bss based on the largest size that ld saw while scanning archives, NOT the largest size actually participating in the link. There was in fact a bug in stdio that relied on this (mis-)feature. It drove me bonkers when I ported the VMS linker to Ultrix. -Paul W.