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