nall@loligo.cc.fsu.edu (John Nall) (09/26/89)
There have been several messages over the past several days (weeks?)
dealing with the problem of library ordering. Some time ago, actually
around the time that 1.3d came out, there was a lot of activity
regarding this. As I recall, ast sent out a message showing the
library order he was using, and most of us tried to copy that. It
was not easy to do even then, but with a bit of work it could be
done.
Now, however, there are easier ways. The easiest way, in my
judgment, is to use Turbo C for doing the Minix compiles
and links (using the material posted by Deborah Mullen). Not only
is the library ordering immaterial, but the resulting object code
tends to be smaller and faster.
For those who for one reason or the other don't have access to
that, there was a package posted by Lee McLoughlin back in
February of this year which also works fine. I am (hopefully
with permission) enclosing that message below. The stuff should
be available in one of the archives. Or, I'd be glad to ship it
to someone who wants to try it.
-----------------------------------------------------------
Date: 5 Feb 89 15:23:49 GMT
Sender: lmjm@doc.ic.ac.uk
Reply-To: lmjm@doc.ic.ac.uk (Lee McLoughlin)
Organization: Dept. of Computing, Imperial College, London, UK.
Lines: 714
All this is aimed at people with hard disc's. Heaven knows how you rebuild
libc.a on floppies.
I just faced the problem of rebuilding libc for 1.4. Since make can't
handle a setup that large I decided to write a shell script to do it.
It needs a couple of auxillary programs. One to check if one file is
newer than another (you can do it with find - but its a pain). The other
just splits up tsort output. I've used various hints from postings on the
net but blame me for any problems.
To make things more manageable I've split minix/lib into subdirectories and
moved things around. All the compiler support is in CC_I8088/, ibm specific
stuff in IBM_PC/, the rest of the library source in src/. The bins/ directory
is where .s files end up either as src/ files get compiled or by being
copied from compiler support or ibm specific. The 'run' shell script
fakes being a makefile and compiles any src/ files that are newer than
the .s file in bins/ and moves the new .s file into bins/. It then creates
a temp libc.a so that it can be lordered and tsorted. The resultant
list is then split up and used to create a new archive.
In the below shar file. 'du' is the the output of du on lib/ showing
how I've I've split up the sources (ignore the SVC directories).
'newer.c' and 'sptonl.c' are the sources for the two auxillary programs
- since the programs are not generally useful I leave the executables
in the lib/ directory. 'run' is the new generation script.
You need to compile newer.c and sptonl.c, move the source around change
run (if necessary) and then type 'run'. If you know that currently nothing
needs to be rebuilt then cd to the bins directory and do 'ar x' on your
libc.a. Since the extracted files will all be newer than the sources 'run'
will believe that everything is up to date.
'run' has a lot of variables at the start. I know others have already
split up their lib/ directory so I've tried to allow for that. 'run' is
a bit space expensive as it requires all the sources, the .s files in bins/,
a temporary copy of libc.a and the generated libc.a
Please let me know of any problems.
Lee.
======================================================================
John Nall Internet: nall@nu.cs.fsu.edu
Computer Science Department Florida State University
"Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"