rsalz@bbn.com (Rich Salz) (08/04/89)
In <10659@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >.... System V "ar" takes care of this >automatically and so there is no need for a separate "ranlib" operation on >System V. The only problem with this is that there is just no way to shut it off. In building a fairly library (400 files in 20 directories) as much as one-third of our time is wasted by doing all that ranlib stuff for every single file. At least in the BSD scheme I can just do it once after I've put the bulk of the library together. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/04/89)
In article <1920@prune.bbn.com> rsalz@bbn.com (Rich Salz) writes: -In <10659@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: ->.... System V "ar" takes care of this -The only problem with this is that there is just no way to shut it off. Doesn't the "q" option do that? Seems like it should.
rsalz@bbn.com (Rich Salz) (08/04/89)
In article <1920@prune.bbn.com> I wrote that the builtin table of contents (TOC) stuff makes building large libraries take too long. In <10663@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Doesn't the "q" option do that? Seems like it should. I'm not sure, but it seems that "q" just zaps the module at the end of the file, but still rebuilds the TOC anyway. Even if it works/worked right, however, it still doesn't solve my problem. I've got a big library (400 files in 20 directories) and I'm going to be replacing about 20 modules (scattered over, say, 10 directories) in that library. About a half-hour of time is WASTED as "ar" creates a TOC 10 times. It would be much more effective if I could NOT build the TOC until the end. I used to agree that having ranlib as a separate command was a real crock, but then I had to use the SysV-oid version of ar... /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
guy@auspex.auspex.com (Guy Harris) (08/05/89)
>->.... System V "ar" takes care of this >-The only problem with this is that there is just no way to shut it off. > >Doesn't the "q" option do that? Seems like it should. Perhaps it should, but I checked the code, and it doesn't; the "rebuild the symbol table" operation is performed whenever any operation that updates the archive is performed ("ar d", "ar q", "ar m", and "ar r", as well as "ar s" which *just* updates the symbol table). I would prefer it that way - you may not want to update the archive with "ar q" (since it can only be used to *add* members to an archive, not replace existing members, nor move members, nor delete members), so a "don't update the symbol table" feature needs to be a modifier applicable to all such commands; given that, I'd prefer to have *all* operations that update the archive update the symbol table by default, to follow the Principle of Least Surprise. Updating the table of contents on all operations that update the archive isn't a problem if you update the library in one command, rather than e.g. replacing each library member with a separate "ar" command; I think, in fact, that the latter would even be faster with versions of "ar" that *don't* automatically update the symbol table. I can appreciate that it might be less convenient to do so, though....
chris@cetia.UUCP (Chris Bertin) (08/07/89)
> In article <1920@prune.bbn.com> I wrote that the builtin table of contents > (TOC) stuff makes building large libraries take too long. > > It would be much more effective if I could NOT build the TOC until the > end. I used to agree that having ranlib as a separate command was a real > crock, but then I had to use the SysV-oid version of ar... > /r$ I modified ar.c, ages ago, to recognize the environment variable 'RANLIB'. If this variable is set to 'noauto', the TOC update is not done. With the same modification, if you link ar to ranlib, it will do the TOC update only. I thought the environment variable approach was more portable than adding a flag, since it would just be ignored if ar did not know about it. I compile everything large with: AR="RANLIB=noauto ar" and then do the following when I need to use the libraries: @[ -z "`type ranlib`" ] || ranlib xyz.a Here is a context diff of the changes. --------------------------------------------------------------------------- *** /tmp/geta19136 Mon Aug 7 11:03:07 1989 --- /tmp/getb19136 Mon Aug 7 11:03:07 1989 *************** *** 131,138 **** int (*comfun)(); - main(argc, argv) int argc; char **argv; --- 131,140 ---- int (*comfun)(); + int quick; + char *rl = "ranlib"; + extern char *getenv(); main(argc, argv) int argc; char **argv; *************** *** 143,148 **** --- 145,163 ---- for (i = 0; signum[i]; i++) if (signal(signum[i], SIG_IGN) != SIG_IGN) signal(signum[i], sigdone); + if (!strcmp(cp = *argv, rl) || + ((cp = strrchr(*argv, '/')) && !strcmp(cp+1, rl))) { + if (argc != 2) { + fprintf(stderr, "Usage: %s lib\n", cp); + exit(1); + } + arnam = argv[1]; + mksymtab(); + done(0); + } + if ((cp = getenv("RANLIB")) != NULL && + (!strcmp(cp, "noauto") || !strcmp(cp, "NOAUTO"))) + quick++; if (argc < 3) usage(); cp = argv[1]; *************** *** 224,230 **** update = (flg['d' - 'a'] | flg['q' - 'a'] | flg['m' - 'a'] | flg['r' - 'a'] | flg['u' - 'a'] | flg['s' - 'a']); (*comfun)(); ! if (update) /* make archive symbol table */ mksymtab(); done(notfound()); } --- 239,245 ---- update = (flg['d' - 'a'] | flg['q' - 'a'] | flg['m' - 'a'] | flg['r' - 'a'] | flg['u' - 'a'] | flg['s' - 'a']); (*comfun)(); ! if (update && !quick) /* make archive symbol table */ mksymtab(); done(notfound()); } --------------------------------------------------------------------------- -- Chris Bertin | -- CETIA -- 150, Av Marcelin Berthelot, Z.I. Toulon-Est +33(94)212005 | 83088 Toulon Cedex, France | inria!cetia!chris #! r
rsalz@bbn.com (Rich Salz) (08/07/89)
In article <867@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: >lorder(1) exists under bsd but is really not necessary with ranlib. In <14194@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >Conversely, ranlib is not really necessary if you have lorder and tsort. Nope. To use lorder/tsort you need to have all the .o files around, while ranlib just needs the .a and space to make a new one. Also, on some systems the result of doing ar r lib.a `lorder ... | tsort` makes a commandline that's too big (hint: think lots of directories). /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.