Whats Missing?
Jerry Berkman
jerry at violet.berkeley.edu
Tue Sep 26 04:45:56 AEST 1989
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 )
More information about the Comp.unix.cray
mailing list