Re: [TUHS] Deleted lib1 and lib2 in v6, recoverable?

[Warner Losh <imp@bsdimp.com>]

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

On Sun, Dec 30, 2018, 1:49 PM <ron@ronnatalie.com wrote:

> 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.
>


Tsort/lorder put them in dependency order. Ranlib gave the index of symbols
as the first or last archive member... in time, the indexing moved up into
ar....

Warner


> > -----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.
>
>

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