Whats Missing?

[Jerry Berkman]

In article <683 at orange19.qtp.ufl.edu> bernhold at orange19 (David E. Bernholdt) writes:
>In article <1989Sep22.002411.6208 at agate.berkeley.edu> jerry at violet.berkeley.edu ( Jerry Berkman ) writes:
>>"bld" seems to provide all the functionality of "ranlib".
>
>Well okay, but I can put that in my makefiles about as easily as I can
>replace ranlib with `lorder | tsort`.  The point is that I have 60
>makefiles for numerous programs and I don't want to have to modify
>them all.
> 

I sympathize, but I don't think adopting "ranlib" as the standard way
to make libraries is a good idea.  I believe in portability and
generally would like utilities to be universally available with the
same options on all systems.  However, I have always regarded "ranlib"
as a kludge, not a well designed library maintenance utility, so I am
glad that Cray has written "bld" to try to have a good library
maintenance utility in UNICOS.  My perspective is as a maintainer of
large Fortran libraries, e.g.  IMSL and NAG, each which contains up to
2000 subprograms.

First of all, bld is a single maintenance utility; ranlib requires
ar and usually both must be used in any maintenance activity.
This is both a nuisance and, for large libraries, a waste of time.

Second, bld allows specification of files or subprogram units;
ar/ranlib only know of files.

Third, bld libraries do not rely on a time stamp kludge which
is easily confused.  If you simply use "cp" to copy a ranlib
file, it is treated as if it is not a library.
In another reply, Keith Sklower notes:
>3.) The check in ``ld'' (that the creation date of the archive is the
>    same as the creation date of SYMDEF) is only a warning
>    and not a fatal error in of itself.
However if the entries in the archive are not properly ordered,
then the load fails.  For example, assume "hello.c" contains:
	main()
	{
		printf("hello, world\n");
	}
Then:
	cc -c hello.c 
	ld -X /lib/crt0.o hello.o -lc
correctly load a modules which will print "hello, world", but:
	cc -c hello.o
	cp /lib/libc.a libc_copy.a
	ld -X /lib/crt0.o hello.o libc_copy.a
fails with undefined externals.

If the files are ordered so that the copy can still be used as
a library, the load will work, but be very slow.

And I just don't like the time-stamp usage.  It can be tricked,
e.g., consider the following commands which are slightly out of
order:

	% /bin/rm -f lib.a
	% ar rv  lib.a sub1.o sub2.o
	% ranlib lib.a
	% ar rv lib.a newsub.o
	% f77 callnew.f lib.a

If executed, quickly, i.e. sourced from a file, the loader thinks lib.a
is up-to-date even though it is not, and the load of junk.f loads uses
the out-of-date table of contents and fails.  Worse things could happen
if you are replacing a object file.

	- Jerry Berkman

( usually disclaimers apply: I speak only for myself, not for UC, CCS,
CSRG, or anyone else )