Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!bionet!agate!violet.berkeley.edu!jerry From: jerry@violet.berkeley.edu ( Jerry Berkman ) Newsgroups: comp.unix.cray Subject: Re: Whats Missing? Message-ID: <1989Sep25.184556.7893@agate.berkeley.edu> Date: 25 Sep 89 18:45:56 GMT References: <3199@amelia.nas.nasa.gov> <681@orange19.qtp.ufl.edu> <1989Sep22.002411.6208@agate.berkeley.edu> <683@orange19.qtp.ufl.edu> Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44) Reply-To: jerry@violet.berkeley.edu ( Jerry Berkman ) Distribution: comp.unix.cray Organization: University of California, Berkeley Lines: 71 In article <683@orange19.qtp.ufl.edu> bernhold@orange19 (David E. Bernholdt) writes: >In article <1989Sep22.002411.6208@agate.berkeley.edu> jerry@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 )