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,HTML_MESSAGE,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 ce0c0754 for ; Thu, 19 Jul 2018 16:13:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7C07C9ED43; Fri, 20 Jul 2018 02:13:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 0A5189E982; Fri, 20 Jul 2018 02:12:42 +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=IFZZ6rTB; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 4ED7C9E982; Fri, 20 Jul 2018 02:12:40 +1000 (AEST) Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by minnie.tuhs.org (Postfix) with ESMTPS id 013929E3BA for ; Fri, 20 Jul 2018 02:12:39 +1000 (AEST) Received: by mail-wm0-f68.google.com with SMTP id s9-v6so6794151wmh.3 for ; Thu, 19 Jul 2018 09:12:38 -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=fH8ZLNTzYaS9TLb+UjnPgWmPKkX6V7zRUHnQIsJLla4=; b=IFZZ6rTBkXJrjU1DpsJXgTrrEaqTl560CDtzQDvzQAJbfBUXviDzCxj3jQLbmIEw+O UOm4suXkGQ0soTxnsLG4plHFxJ+Ur9hU36FhZOPmfX8FaXd7EUTvQzHDTiUKEAA5QAnD mKgeRxa/3Q8FfXjxjPtVtmaFmoHhaNxuqE6hSKB6dXxudtHfa8afVUU0LnyHQvuhGJRN cgFFGzDb4AM9iEDQA2vXJ912oJrIuFXHBCTVXLsWvf44Y/xSsl9Uli0lLW+QEMGHUBfI Wyx0vPF9nKIYjEj/IfLfE0DmY9K+gsCUa0ZV1ilz/pVw9VCNATV6gRtjzuZLCNma0fuP Eltg== 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=fH8ZLNTzYaS9TLb+UjnPgWmPKkX6V7zRUHnQIsJLla4=; b=fSDm+SMFBGB2lhI1GyTfIDDP7jMCcsix9/tYILF17ik4daSn0EKES+AeR2nUHdhWn+ v51UhzqK9oapwHwA0HV9T+QuPnUeq79nAxJ7MIcQLOYd9m+XT3BqAs03GlDCq42tCIUL BNCuVdGPb0Q6q9UTP7GruGoQtTZgs9T2ZMMlTMLIpod269NoxtGZQ76rxbBLpncQ0Bla O7qs5bbhQz7hHHiTEQac+sJ/bfVUnkhe9fTGwJAcWuxs1nI2v4UDkxnfTiTam0n0J6HY QbQ7zqePgZ1aewj83y8gqvZiDXWeoKz6WVzh9awGrGTo3KyUuEEgx14nna7jyxJ+Qcsl 3kOw== X-Gm-Message-State: AOUpUlEPuSrjF4JbPqVCXCruIepCne1+tMiAbaRMkTj3FSmSOJzAGLeh QAxtGTgYntc0pyOBzsKNdSNdC94xvBiasoKm9XE= X-Google-Smtp-Source: AAOMgpcO8yJjKTPX7cjdj16uxyZnOo7bYa/ZbMz+moMf0kDAXKC16qLmuBlizcTwglxojNl8jqzFU4DCrkV5ddOFWTY= X-Received: by 2002:a1c:be13:: with SMTP id o19-v6mr4388314wmf.1.1532016757559; Thu, 19 Jul 2018 09:12:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:8f64:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 09:12:37 -0700 (PDT) In-Reply-To: References: <201807171320.w6HDKNTR023268@freefriends.org> <201807181739.w6IHdUZW004045@freefriends.org> <20180719045909.GD54853@eureka.lemis.com> From: "John P. Linderman" Date: Thu, 19 Jul 2018 12:12:37 -0400 Message-ID: To: Paul Winalski Content-Type: multipart/alternative; boundary="0000000000009fe1d705715c7219" 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: The Eunuchs Hysterical Society , Peter Weinberger Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000009fe1d705715c7219 Content-Type: text/plain; charset="UTF-8" A few long-dormant brain cells woke up and convinced me that ranlib was done by Peter Weinberger. Perhaps Doug or Peter can confirm or refute the memory. On Thu, Jul 19, 2018 at 11:29 AM, Paul Winalski wrote: > >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. > --0000000000009fe1d705715c7219 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A f= ew long-dormant brain cells woke up and convinced me that ranlib was done b= y Peter Weinberger. Perhaps Doug or Peter can confirm or refute the memory.=

On Th= u, Jul 19, 2018 at 11:29 AM, Paul Winalski <paul.winalski@gmail.com<= /a>> wrote:
&g= t;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 wh= en
> 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.=C2=A0 At some
point ranlib seems to have been integrated into ar.=C2=A0 When did this
happen?

The version of ranlib from the mid-1980s had an implementation that
was a bit too simple-minded.=C2=A0 It indexed all symbols with N_EXT set and a non-zero n_value field.=C2=A0 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.=C2=A0 ranlib should have filtered out symbols
that have N_UNDF set as well as N_EXT.=C2=A0 ld had a faulty work-around for this problem.=C2=A0 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.=C2=A0 But by this= time ld
had already maximized the sizes of all common symbols, and that didn't<= br> get backed out.=C2=A0 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.

--0000000000009fe1d705715c7219--