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

[Will Senn <will.senn@gmail.com>]

Ah! Thanks Noel. Yes, the two files are created and then a slew of linker errors.  What you say makes sense. I can just compare with another v6 instance that I have that is similar to replicate the delivered order. Now I’m off to trying it out.


Will


Sent from my iPhone

On Dec 28, 2018, at 7:09 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>> From: Will Senn
> 
>> I whacked /usr/sys/lib1 and lib2 'accidentally' meaning I logged in as
>> bin changed to /usr/sys and typed rm lib1 and rm lib2 :).
> 
> Doesn't sound very accidental... :-)
> 
>> sh run as bin doesn't do it.
> 
> Odd. 'run' in /usr/sys on my V6 machine (not that I use that, mind) says:
> 
>  chdir ken
>  cc -c -O *.c
>  ar r ../lib1
>  rm *.o
>  chdir ../dmr
>  cc -c -O *.c
>  ar r ../lib2
>  rm *.o        
> 
> which should regenerate them - sort of. I suspect you really meant 'doing sh
> run creates a lib1 and lib2, but then I get errors from the ld phase with
> missing symbols'. Yes?
> 
> 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.) In other words, when loading a multi-module system,
> the module with 'main' has to be first, and then the rest in an order such
> that each one holds a previously-undefined symbol.
> 
> So the order of the object modules you'll get in lib? from the above, if you
> precede them with 'rm lib?', is probably not the right order. (The above shell
> script assumes they already exist, with the modules in the right order, so the
> above just replaces them with the newly compiled versions...)
> 
>> So, what magic incantation is required to rebuild them.
> 
> Here's the ordering in lib1:
> 
>  main.o
>  alloc.o
>  iget.o
>  prf.o
>  rdwri.o
>  slp.o
>  subr.o
>  text.o
>  trap.o
>  sig.o
>  sysent.o
>  clock.o
>  fio.o
>  malloc.o
>  nami.o
>  pipe.o
>  sys1.o
>  sys2.o
>  sys3.o
>  sys4.o   
> 
> Other orders would work too (e.g. you could move sys?.o up just after sysent.o
> and it should work).
> 
> My lib2 is somewhat odd, so I hesitate to list it, but since most modules in
> dmr are pulled in from entries in c.c, almost any order will work, I think.
> 
>    Noel