The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "John P. Linderman" <jpl.jpl@gmail.com>
To: Paul Winalski <paul.winalski@gmail.com>
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>,
	Peter Weinberger <pjw@google.com>
Subject: Re: [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]]
Date: Thu, 19 Jul 2018 12:12:37 -0400	[thread overview]
Message-ID: <CAC0cEp_nL9fj9iu-ZwJ6qcMkhDbOdPY+tKd1N5akQcKVr1xebg@mail.gmail.com> (raw)
In-Reply-To: <CABH=_VQUCEfLfB3s_p2_LwKNtMEMxkC269=rEc1vCR8FoH2UFw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

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 <paul.winalski@gmail.com>
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.
>

[-- Attachment #2: Type: text/html, Size: 2538 bytes --]

  reply	other threads:[~2018-07-19 16:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17 12:33 [TUHS] Speaking commands [Was: Bell System Technical Journal archive] Nemo
2018-07-17 13:20 ` arnold
2018-07-17 14:39   ` John P. Linderman
2018-07-18 17:39     ` arnold
2018-07-19  4:59       ` [TUHS] ar libraries [was: Speaking commands [Was: Bell System Technical Journal archive]] Greg 'groggy' Lehey
2018-07-19 15:29         ` Paul Winalski
2018-07-19 16:12           ` John P. Linderman [this message]
2018-07-20 23:01     ` [TUHS] Speaking commands [Was: Bell System Technical Journal archive] Kurt H Maier
2018-07-18  0:56   ` Ron Natalie
2018-07-18  3:54     ` arnold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC0cEp_nL9fj9iu-ZwJ6qcMkhDbOdPY+tKd1N5akQcKVr1xebg@mail.gmail.com \
    --to=jpl.jpl@gmail.com \
    --cc=paul.winalski@gmail.com \
    --cc=pjw@google.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).