The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: <ron@ronnatalie.com>
To: <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
Date: Sun, 30 Dec 2018 13:48:38 -0500	[thread overview]
Message-ID: <128301d4a070$4794ea70$d6bebf50$@ronnatalie.com> (raw)
In-Reply-To: <CABH=_VRr1KPuXVXQysF_9R2DqNpYZeEiiD5RErgZDRqnQ9Mhaw@mail.gmail.com>

Yes, it pretty much has to be this way as it is a single pass process and the ar format is simple.
The later libraries have a symbol "dictionary" added to the beginning.   Before that you manually arranged the order of the relocatables in the library and later automated tools to put them in dependency order (ranlib, etc...) came about.


> -----Original Message-----
> From: TUHS <tuhs-bounces@minnie.tuhs.org> On Behalf Of Paul Winalski
> Sent: Sunday, December 30, 2018 1:34 PM
> To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
> Cc: tuhs@minnie.tuhs.org
> Subject: Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?
> 
> On 12/28/18, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> >
> > If so, the thing is that the V6 linker won't pull in an object module
> > from a library unless a global in it satisfies an already existing
> > (i.e. in the linking process) undefined global. (I don't know if this
> > is true of later linkers; never used 'em.)
> 
> I think this has been pretty much universal behavior for all linkers on all OSes
> since the 1960s.  It continues to be true today.
> 
> Sometimes one runs into a situation where a module loaded from lib1.a has
> an undefined symbol that causes a module from lib2.a to be loaded, and that
> module in turn has an undefined symbol that is defined in lib1.a.  In that
> case, you have to cause the linker to scan lib1.a
> twice:
> 
>     ld main.o lib1.a lib2.a lib1.a
> 
> -Paul W.


  reply	other threads:[~2018-12-30 18:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-29  1:09 Noel Chiappa
2018-12-29  1:26 ` Will Senn
2018-12-29  1:35 ` Warren Toomey
     [not found]   ` <82e23dba-38a4-3ee4-e35a-6293b8eef749@gmail.com>
2018-12-29  4:59     ` Warren Toomey
2018-12-29 16:26       ` Clem Cole
2018-12-29 16:49         ` Warner Losh
2018-12-29 17:48           ` Clem cole
2018-12-30 18:34 ` Paul Winalski
2018-12-30 18:48   ` ron [this message]
2018-12-30 18:56     ` Warner Losh
2018-12-30 19:02     ` Paul Winalski
2018-12-31  0:00   ` Donald ODona
2018-12-31 17:51     ` Paul Winalski
  -- strict thread matches above, loose matches on Subject: below --
2018-12-31  3:22 Rudi Blom
2018-12-31  2:28 Doug McIlroy
2018-12-31  3:34 ` Will Senn
2018-12-31  6:52   ` ron
2018-12-30 19:07 Norman Wilson
2018-12-30 19:24 ` Paul Winalski
2018-12-31  6:57 ` arnold
2019-01-02 13:54   ` Tony Finch
2018-12-29 14:13 Noel Chiappa
2018-12-29  0:25 Will Senn

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='128301d4a070$4794ea70$d6bebf50$@ronnatalie.com' \
    --to=ron@ronnatalie.com \
    --cc=tuhs@minnie.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).