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.
Sent from my iPhone
On Dec 28, 2018, at 7:09 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
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:
cc -c -O *.c
ar r ../lib1
cc -c -O *.c
ar r ../lib2
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
Here's the ordering in lib1:
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.